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Preface 



Background 



Persons familiar with the history of programming will realize that the development 
of the Commercial Translator system is a logical step in the evolution of program- 
ming systems. The step from machine language coding to symbolic coding systems 
such as those for the ibm 702 and 705 was a natural and relatively simple develop- 
ment. With the introduction of "soap" for the ibm 650, "sap" for the 704 and 
"Autocoder" for the 705, it became possible to write programs using English lan- 
guage words or abbreviations instead of symbolic numbers. A parallel development 
was the concept of writing one synthetic instruction, i.e., a macro-instruction, to 
represent several machine operations. Several systems at this level of development 
are a combination of the "one-for-one" coding of symbolic languages and the 
"several-for-one" coding of macros. Although these systems greatly simplify pro- 
gramming, they are all essentially machine-oriented; that is, the programmer must 
think in terms of the operation repertory of the particular machine. A highly signifi- 
cant step occurred with the advent of compilers such as Fortran. For the first time, 
coding systems were designed in terms of the language of the problem to be coded 
instead of in terms of a specific data processing system. The Fortran language is 
used to formulate mathematical problems for several data processing systems. It 
naturally preceded the development of the Commercial Translator system since it is 
directly related to the language of mathematics, the forms of which are accepted uni- 
versally. Now, with Commercial Translator, a problem-oriented language becomes 
available for the formulation of commercial problems. 



Concerning 
this Manual 



The primary purpose of this manual is to present the Commercial Translator system 
in sufficient detail to permit the programming of applications in its language. Certain 
information is omitted: Separate publications will describe the operation of the 
processors, i.e., the programs for each data processing system which translate the 
Commercial Translator language into the machine language of that particular sys- 
tem. These publications will also cover the rules for stating environment descrip- 
tion, which is the portion of a Commercial Translator program that specifies the 
available components of the data processing system and the external characteristics 
of the files to be processed. 



Chapter 1: General Description of the Commercial Translator 

System 



Introduction and Plan of the Manual 

This manual has been written to be useful to two different groups of readers. 
Chapters 2 through 4 present a comprehensive description of the Commercial 
Translator language. The reader with experience in data processing may therefore 
begin immediately with Chapter 2. The present chapter contains a brief discussion 
of the essential characteristics of data processing systems (language questions 
aside), an indication of the motivation that led to the Commercial Translator 
language, and a number of relatively simple graded examples. These examples 
introduce the fundamentals of the Commercial Translator language without 
attempting to be complete. 

This chapter then is intended to be of assistance to the new user who has had 
little or no experience in data processing. 

Designing Data Processing Programs 

Suppose you have been assigned to a team that is to set up a data processing system 
for some application in payroll, or inventory control, or utility billing, or insurance, 
or even in an area of science or engineering. What do you need to know about data 
processing in order to use the Commercial Translator language on such a job? 

To begin with, we can mention a few areas of knowledge that are not needed. 
You need no knowledge of electronics. You need no knowledge of mathematics 
beyond high school algebra (unless, of course, the problem itself is mathematical). 
With the Commercial Translator language you do not even need a detailed knowl- 
edge of how your particular computer system works. However, you do need to know 
certain facts about data processing, and eventually, if you work with the subject for 
a while, you will pick up certain detailed facts about your particular computer— but 
you do not need these now. For now, the general ideas which you should have are 
discussed below. 

What Is a Data Processing System? 

A data processing system is composed functionally of five parts, as shown in 
Figure 1. The input section accepts information "from the outside," and converts 
it into the electronic form in which it is manipulated and stored internally. Exter- 
nally, information is typically recorded on punched cards, punched paper tape, or 
magnetic tape. In some applications, printed characters can be read directly. 
Presently-used business machines cannot recognize handwriting or speech. The 
output section of a computer has the obvious function of converting from the 
internal representation to some convenient external form, such as printing, punched 
cards, magnetic tape, punched paper tape, or a variety of specialized media. Though 
the speeds of all of these devices are much greater than those of manual devices, 
they are still generally quite slow compared to speeds of internal electronic manipu- 
lation. The kind and number of input and output devices naturally depends on the 
particular machine and its application. 

The storage section of a computer serves two important purposes. The obvious 
function is to hold the data on which we wish to operate. A function less obvious 
to the newcomer is to hold coded instructions which we place there to specify the 
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Communication with 
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Machine 



procedure we wish to follow. A collection of such instructions, about which we 
shall have more to say later, is called a program. There are usually two types of 
storage. One type, though very fast, is of limited capacity and quite expensive; it is 
called main storage. What is frequently termed auxiliary storage can hold much 
more information, but is substantially slower. 
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Figure 1 

The last two sections of a computer are called the logical-arithmetic section and 
the control section. The actual data processing is done in the logical-arithmetic 
section, and the control section is needed to decode and interpret the instructions 
in storage. 

A most important feature of modern data processing machines is the way instruc- 
tions are held in main storage right along with the data. For this reason we speak 
of a stored-program machine. The machine is therefore able to carry out arithmetic 
on its own instructions with the result that a program can be designed to modify 
itself and selectively repeat certain sections. 

The instructions which a data processing machine can execute naturally vary 
from one machine to another, but they can still be grouped into general categories. 
One group is used for arithmetic operations, another for making the elementary 
"decisions" of which a data processing machine is capable. Still another group covers 
input/output operations and a fourth group carries out miscellaneous control func- 
tions which are required because of the way the machine operates. Most individual 
operations are quite elementary, requiring that a large number of them be combined 
properly in order to carry out a meaningful data processing task. This work, which 
follows the complete definition of the processing task, is called programming. 

Data processing requires an extremely precise statement of the problem. We must 
not say "less than 30" if we mean "less than or equal to 30." There is no way we 
can say, "make sure the data looks reasonable"; if we want to check the validity of 
data, we must specify exactly what tests are to be made on it. 

With data processing, we are required to detail our procedures in advance to a 
degree not found in other methods. If we were asking a clerk to do a job, we might 
end by saying, "and if you run into anything you don't know how to handle, call me 
and we'll figure out what to do." In order to do a similar thing with a data processing 
machine, it is necessary first to define precisely what constitutes an exception, and 
then to write a procedure to handle it. 
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Examples 



Example 1 



The initial definition of a business data processing problem usually involves some 
type of flow chart, often combined with a written description of the procedure to be 
followed. In order to be handled by a data processing machine, the procedure must 
be expressed in the machine's own coded, elementary instructions. In the past, it 
has been necessary for the programmer to make the translation between these two 
markedly different languages. Learning to do so is a matter of many months of 
training and experience. 

The Commercial Translator makes it possible to let the machine itself do much of 
this translation. Now, we need only restate the procedure in a series of formal pro- 
cedure statements and then let the Commercial Translator processor carry out the 
remainder of the translation to produce actual machine instructions. 

Stated in the terms we shall use in this manual, the Commercial Translator proc- 
essor (which is itself a specialized program) converts from a source language (the 
procedure statements) to an object language (the machine instructions). 

An important advantage of writing procedure statements in the Commercial 
Translator language is that they do not depend on the characteristics of the data 
processing machine on which they will be used. In the terminology of the field, we 
would say that the procedure statements are machine-independent. For each type 
of machine there must be an associated processor, but the different processors will 
all accept the same procedure statements. This naturally means that transferring a 
problem from one machine to another is a far simpler task than before. 
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description which describes the problem data. The data description is not entirely 
machine independent, but rather depends to some extent on the characteristics of 
the type of machine being used; it probably will need some revision if it is necessary 
to transfer the problem to a different machine. 

It turns out to be a major advantage that the procedure description and the data 
description are separate because changes are much easier to make. With this inde- 
pendence, if a modification of the procedure is required, we do not have to change 
the data description; we simply change the affected part and use the processor 
again. Correspondingly we can change the data description without modifying the 
procedure. 



The examples which follow introduce the fundamental concepts of Commercial 
Translator procedure description and data description. It is not intended that these 
examples should present all of the information about the Commercial Translator 
language; later parts of this manual do that. This part is intended only to introduce 
the subject in a manner which may facilitate learning. 

The central feature of a billing procedure is the multiplication of the unit price by 
the quantity sold. A sentence in a Commercial Translator program to do this 
could be : 
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This is the equivalent, in Commercial Translator language, of the following pro- 
cedure statement: 

Multiply UNIT.PRICE by QUANTITY to get the TOTAL.PRICE. 

In the example set is a word which has a specific meaning in the Commercial 
Translator language; namely, it is a command to carry out the arithmetic procedure 
specified by the rest of the sentence, set simply states that the calculation following 
the equal sign is to be performed. 

The asterisk ( * ) in this example is used to indicate multiplication, instead of an X 
or a centered dot, to avoid possible confusion. For the same reason we use the 
slash (/) to indicate division and a double asterisk (**) to indicate taking the power 
of a number (exponentiation). The names of the operations, together with the ac- 
ceptable symbols which are used in writing arithmetic expressions, are shown in 
Chapter 2 on page 21. 

As can be seen from the example, a Commercial Translator sentence is very 
similar to an ordinary English statement in construction and format. Actually, the 
parallel extends to some aspects of punctuation. A Commercial Translator sentence 
always ends in a period. Data is referred to by name, such as total. price. The 
major exception is that names consisting of more than one English word must be 
constructed with "imbedded" periods since in the Commercial Translator language 
a space always means a new name. 

A name may be formed by any combination of the 26 letters of the English 
alphabet and the 10 digits, as long as it begins with a letter. The imbedded period 
may be used freely, except that it may not be the first or last character. A valid 
name can be of any length up to thirty characters. 

There are, of course, differences between the Commercial Translator language 
and ordinary English construction. There is a standard format which must be ob- 
served. In the Commercial Translator language there is also a greater need for 
preciseness; for instance, total. price must always be spelled in exactly the same 
way. This implies that we don't have the same semantic flexibility as in normal 
English. A particular name must be used to mean just one thing in a given program. 

Although this example, which is used to illustrate the simplest ideas about the 
Commercial Translator language, is based on a price calculation, it might have been 
based on computations from many different fields. It might just as well have dealt 
with payroll, or inventory control, or insurance, or mathematical work in engineering. 

Example 2 For a second example, consider a part of an inventory calculation. One sentence 

of the Commercial Translator procedure for determining whether or not to place an 
order might be: 
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The first word, reorder.routine, is called a procedure-name. This is indicated 
by the fact that it begins in the procedure-name area of the programming form and 
is followed by a period. A procedure-name provides a way of referring to the 
sentence which follows. 



The sentence illustrates a conditional expression involving a simple relation 
between two quantities. If the quantity. on. hand is less than the minimum (in 
other words, the reorder point), the action specified following then is carried out. 
If quantity.on.hand is not less than the minimum, the action following then is 
not carried out. 

Figure 2 shows in schematic form the structure of this sentence. 
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Figure 2 

The if.. .then construction is one of the most important features of the Com- 
mercial Translator language. The conditional clause, which is introduced by the 
word if and concluded by then, in effect asks a question to which the answer must 
be yes or no. We shall speak of each relation involved in a conditional expression as 
being true or false, or satisfied or not satisfied. This example uses the is less than 
relation. The allowable relations, and the Commercial Translator words which may 
be used to express them, are shown in Figure 3. 
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IS EQUAL TO 


— 
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IS GREATER THAN 


GT 


IS NOT GREATER THAN 


NOT GT 


IS LESS THAN 


LT 
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Figure 3 





Example 2 also shows a different command, move. ..to. The action called for is 
the copying of information within storage. The information named order.quantity 
is to be copied and called purchase.amount. 

It is probably apparent by now that certain words have special meanings in the 
Commercial Translator language: in the present example, the words if, then, 
move, to and the phrase is less than all have special meaning, and confusion 
would result if we tried to interpret these words in any other way. Such words are a 
fixed part of the language. A complete list of the Commercial Translator words 
appears in Appendix 2 at the end of the manual. Incidentally, the inference one 
might draw from the statement above is correct: a Commercial Translator program 
consists of just two kinds of words: fixed words, and names which the programmer 
selects. 
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To introduce a few more features of the Commercial Translator we use a common 
payroll example : 
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The conditional clause in this example is different from what we have seen pre- 
viously. The first part of the clause consists just of the word hourly, which is called 
a condition-name, hourly is one of the possible values which can be assumed by 
the implied data-name payroll. type, the other values being exempt, salaried 
and temporary. Since there are only a few of these conditions, it is convenient for 
the programmer to use his normal terminology. The actual machine instructions are 
set up to work with a coded representation of these values, e.g., the numbers 1, 2, 3, 
and 4. Obviously, some way must be provided to correlate the condition-names with 
the corresponding values. Establishing this correspondence is one of the functions 
of the data description. Shown below is the appropriate part of the data description 
required for this example. 
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payroll. type is defined as a level 03 entry which indicates its relative impor- 
tance with respect to other elements of data. The 9 specifies that the data is numeric, 
and the fact that there is only one 9 means that the field consists of one digit. 
exempt, salaried, hourly and temporary are named as the four conditions by 
listing them with cond in the Type columns, and the code number used for each is 
given in quote marks. Thus, in this example, the value of payroll. type is 3 when- 
ever hourly is meant. 

The second part of the conditional clause is: 

HOURS.WORKED IS LESS THAN 40 

In this case the value of the data-name hours. worked is compared with the 
number 40; 40 is not to be interpreted as a data-name, but literally as the value 40 
itself. We speak of 40 as being a numeric literal. 

The second part of the conditional clause is joined to the first part by the fixed 
word and which specifies that both the first part and the second part of the clause 
must be satisfied before carrying out the operations that follow then. This is shown 



schematically in Figure 4, which emphasizes that both parts of the conditional 
clause must be true before carrying out the action specified after then. If either 
(or both) of the parts is false, the action specified after otherwise is executed; if 
otherwise is absent the program continues with the succeeding sentence. 

In the Commercial Translator sentence under consideration, the actions specified 
after both then and otherwise happen to be a new command, go to. The go to 
command makes it possible to get out of the one-af ter-the-other sequential execution 
of sentences and sections and instead execute next the sentence named by the go to. 
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Figure 4 

Construction of These examples are intended to introduce some of the important ideas of the Com- 

the Commercial mercial Translator language with a minimum of formality, and without attempting 
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more meaningful if we pause here to generalize about some of the concepts which 
have been illustrated. 

It may be helpful to think of the Commercial Translator language as existing on 
two different levels. At the first level, we are concerned with the elements of the 
language: characters, fixed words, punctuation, names, literals, etc. In short, we wish 
to define precisely the constituent elements of the language. This is done in Chapter 2. 

The second level of the language, which may be called the syntax of the Commer- 
cial Translator language, has to do with how to fit elements together properly, in 
such a way as to describe the desired procedure. Here we are concerned with the 
rules for grouping words, provisions for joining expressions, techniques for program 
organization, etc. These are covered in detail in Chapters 2 and 3. 

For instance, one basic structural building block is an expression; this is defined 
as any grouping of elements which always establishes a unique value. An arithmetic 
expression can take on any numeric value whereas a conditional expression may 
only be true or false. A true expression is sometimes converted to the value 1 and 
a false expression to the value 0. 

Another concept in the language structure is that of a clause. A clause consists 
of a fixed word or words, together with an associated format or framework into 
which the programmer inserts names and expressions. We may distinguish two types 
of clauses: imperative clauses, i.e., commands, and conditional clauses. 

We have seen examples of commands in set and move operations. We saw that 
in each case there was associated with the command a format: set a name = an 
expression, and move a name to a name. Commands are independent clauses which 
may stand alone. When the source program is converted to the object program, 
commands are converted directly into corresponding machine instructions in the 
object program. 



A conditional clause starts with if and contains one or more conditional expres- 
sions; the actions to be taken if the conditional clause is true are described by 
one or more commands introduced by then. If the conditional clause is false, 
the commands following then are ignored and instead the commands introduced 
by otherwise are executed. Conditional clauses are dependent clauses and must 
always be followed by at least one command. 

Still another concept of the language is that of processor commands. So far, we 
have been discussing program commands, that is, commands which state the data 
processing steps to be carried out by the object program. The processor commands, 
on the other hand, tell the processor how to organize the object program rather than 
what the object program is to do. One kind of processor command, begin section, 
simply tells the processor that the following sentences are to be referred to collec- 
tively by the designated name; it does not directly cause machine instructions to be 
created in the object program. 

The reader may wish to consider the examples which follow in the light of these 
general observations about the elements and structure of the language. 



Example 4 



The fourth example is based on a part of an inventory control calculation. Suppose 
that we already have in storage in the data processing system a complete inventory 
record for one part number, and that there is also in storage a transaction record 
for that part number. Assume that there are just four types of transactions: with- 
drawals, receipts, returns and stock recounts. The part of the job that we wish to 
consider is how to take action appropriate to the type of transaction. The program 
shown below is a little longer than the ones we have seen before, but most of the 
ideas in it are already familiar. 
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The first line of this program brings into play a processor command: 

NOTE INVENTORY RECORD MAINTENANCE. 

note indicates that what appears in the rest of the sentence is information for the 
reader of the program; it is not for the Commercial Translator processor, which 
ignores it. The programmer is permitted and encouraged to use notes freely, in order 
to make the program more intelligible to the reader. 

The go to shown on line 02 is a more powerful form of this command than we 
have seen before : 

CO TO (WITHDRAWAL.ROUTINE, RECEIPT.ROUTINE, 
RETURN.PROCESS, RECOUNT. PROCEDURE) 
ON TYPE.OF.TRANSACTION. 

This is called an assigned go to. For any one transaction, only one of the four 
procedures named in the parentheses will be performed; the one selected will depend 
on the current value of type.of. transaction. Suppose the value of type. of. 
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transaction can vary from 1 to 4. These numbers correspond to the names within 
the parentheses; if the value is 1 the first name will be selected and so on. This is 
summarized in Figure 5. 



If the current value of 
TYPE.OF.TRANSACTION is: 


Then GO TO: 


1 

2 
3 
4 


WITHDRAWAL.ROUTINE 
RECEIPT.ROUTINE 
RETURN.PROCESS 
RECOUNT.PROCEDURE 



Figure 5 

This assigned go to provides a multiple branch or switching point. For those 
with punched card background this may also be thought of as a "digit selection" 
operation. 

Lines 05 and 06 illustrate another use of the set command. It is evident from 
examining this sentence that the equal sign ( = ) in the set command is used to mean 
"replace." set a = b means replace a by the value of b, where b represents any valid 
expression. Thus, in the example, the difference between quantity.on.hand and 
transaction. quantity (to the right of the equal sign) replaces the original 

QUANTITY.ON.HAND. 

Line 07 demonstrates another type of transfer of control: 

DO REORDER.CALCULATION 

The do command may be thought of as meaning "go to the place named, do what- 
ever it says to, and come back." In our case, it is used to transfer to a procedure 
named reorder.calculation and set up a return path so that, after executing that 
procedure, control will return to the command immediately following the do com- 
mand. After performing the reorder.calculation, control will return to, and 
execute, the go to next.item command on line 07. 
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As another illustration of the use of Commercial Translator, we will use a savings 
bank procedure: updating the account record to indicate interest payment. The 
program might look like this: 
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Line 01 shows again the use of a procedure-name to provide a named point to 
which program control can be transferred. In this case it precedes a slightly different 
type of conditional clause. Instead of simply comparing two values as we have 
before, the programmer has indicated that he wishes to see if the value of an arith- 
metic expression (.03 * principal) is less than some numeric literal (1.00). It is 
quite valid to incorporate an arithmetic expression within a conditional expression. 
For clarity, it may often be desirable to use parentheses to denote the beginning 
and end of such an arithmetic expression. 



Outline of Manual 



The careful reader may have noticed what appears to be an error in line 03 : there 
seems to be an imbedded period missing in account balance. However, the omis- 
sion is deliberate; this is an example of name qualification. Remember that in an 
ordinary name, a blank indicates the start of a new word. Here, balance is the 
name of a field of data; account is the name of a record, which includes a number 
of fields. The idea of using record names to qualify field names is that certain field 
names might be fairly common, and that the programmer should not be required to 
think up unique names for every field in every record. Instead, he can name the 
fields in any way that seems reasonable and then identify each field by the record 
in which it appears. Thus, in our example, account balance means the field 
balance which appears in the record account. Of course, a name qualifier is not 
required if a particular name is, in fact, unique. 

There is one other new point to notice in this example. On lines 04 and 05 
we have : 

MOVE 'INTEREST' TO ACTION. 

The quotation marks indicate that the word interest itself is to be moved to the 
area named action. Thus interest is identified by the quotation marks as being an 
alphameric literal. An alphameric literal may contain any characters except the 
quotation mark. 



The following pages are devoted to a detailed description of the Commercial Trans- 
lator language and its application. The description proceeds as follows: 

Chapter 2— This chapter covers the elements, or components, of the Commercial 
Translator language and describes the overall structure of the language. 

Chapter 3— The procedure-describing part of the language is discussed in this chap- 
ter. The various Commercial Translator verbs and the commands in which 
they appear are explained in detail. 

Chapter 4— The rules and conventions for stating the data description are covered 
in this chapter. 

Appendices — 

1 . A sample payroll program written in the Commercial Translator language 
is presented in Appendix 1 . 

2. Appendix 2 contains supplementary information of various kinds for 
reference purposes. 

3. A glossary of terms is included in Appendix 3. 
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Chapter 2: The Structure of the Language 

Underlying Principles 



The structure of the Commercial Translator language is very much like that of 
English. It has, first of all, a basic vocabulary, consisting of words and symbols. Next, 
it has a set of basic rules of "grammar" or "syntax" by which the words and symbols 
may be combined to express meanings. Finally, it has punctuation symbols to clarify 
the groupings of words and symbols so that their meanings will be unmistakably clear. 

The Commercial Translator language is much simpler than English, for its require- 
ments are more limited and more precise. Since it is a programming language, it 
must have the capacity to state facts and give instructions. It must be clear and spe- 
cific; it does not require the ability to express delicate shades of meaning. The Com- 
mercial Translator is a language of action — a language for getting things done — and 
it therefore consists largely of verbs and nouns. The verbs direct the system to take 
action of various kinds; the nouns name the data and the procedures on which action 
is to be taken. 

As in English, verbs and nouns may be combined into clauses and sentences so 
that meanings may be clearly defined. A number of typical Commercial Translator 
sentences have been examined in Chapter 1 of this manual. The reader will thus have 
discovered that he can usually tell what a Commercial Translator sentence means 
merely by reading it, although at this point he may not know the rules for writing 
such a sentence or the ways in which a sentence can be used in a program. It is the 
purpose of this chapter to describe the basic components of the language and to show 
the rules for combining them to express meanings. 
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Character Set 



Verbs 



The words and symbols of the Commercial Translator language are the basic units 
with which the programmer will work, but he should understand that they in turn are 
composed of individual letters, numbers, and special characters — in short the basic 
character set. This set consists of the 26 letters of the alphabet, the ten numerals from 
to 9, and the special characters shown in the table below. 

Special Characters Used in the Commercial Translator Source Language 



Name 



Character 
(Set H*) 



Card Code 



blank 
plus sign 
minus sign 
multiplication sign 
division sign 
left parenthesis 
right parenthesis 
comma 
period 

decimal point 
dollar sign 
equal sign 
quotation mark 



+ 



(blank) 

12 

11 

11-4-8 

0-1 

0-4-8 

12-4-8 

0-3-8 

12-3-8 

11-3-8 

3-8 

4-8 



^Set H is one of several character sets available for ibm equipment. All sets use the same card 
codes, but in the case of special characters, one code may represent one character in one set 
and another character in another set. For example a "12" punch indicates a plus sign in Set H, 
while in certain other sets it represents an ampersand. The Commercial Translator system em- 
ploys the codes of Set H, shown above. 



The uses of these characters will be explained subsequently in this manual. The 
reader should note that the blank is treated as a character, but that a series of blanks 
will be regarded as a single blank, except in alphameric literals or other constants. 



In the Commercial Translator language, a verb is a word that prescribes an action. 
Verbs are not used in a declarative sense in the language, and the programmer should 
recognize from the start that everything he writes will produce some kind of effect. 

The prescribed action may not take place at the time the object program is run. 
In fact, a number of verbs give instructions which the processor will carry out at the 
time the object program is assembled. For example, as the programmer analyzes a 
data processing problem he may recognize that it contains elements which he has 
already handled in solving previous problems. If so, he may have written program 
"routines" that can now be used again. If such a routine has been stored in a 
"library," the programmer may be able to call for it by using the verb include, as 
explained in Chapter 3 of this manual. This verb, therefore, may be used in building 
the object program, but it will not be used as a part of the object program itself. 
Verbs which act on the processor when the source program is translated are called 
processor verbs. 

However, most of the verbs the programmer will write will cause some action at 
"object time" — i.e., at the time the object program is run. Thus, the verb add will 
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Operators 



cause two or more items of data to be added together, the verb display will cause 
specified information to be printed or otherwise displayed, and the verb stop will 
cause the machine to halt. Verbs which act at object time are known as program verbs. 

Not all words that cause action are verbs. For instance, the reader will learn later in 
this chapter how to order that a given action be carried out only if a certain condition 
is met. Consider the sentence if a = b then move a to output. This sentence con- 
tains only one verb, the word move, yet it implies two separate operations. The move 
operation, of course, is one of them; the other is a test to determine if the condition 
a = b has been met. However, the programmer does not have to write a verb directing 
the program to test for this condition, for the word if serves the purpose. The Com- 
mercial Translator language contains several words and symbols (such as the arith- 
metic symbols) which are not verbs but which cause operations. They are called 
operators. 

It is necessary to distinguish between verbs and operators, since they are used in 
different ways. Commercial Translator verbs may be easily recognized by the fact 
that all of them are words which serve also as verbs in the English language. 

For a general indication of how verbs are used, the reader may refer to any of the 
examples used in Chapter 1. The specific rules governing each verb will be found in 
Chapter 3. 



Names 



Most of the words in a typical Commercial Translator program will be nouns. A 
noun, in the strictest sense, is a name, and the programmer will find it very useful to 
accept that definition and all of its implications. He will write procedures for handling 
data, but he will refer to the procedures and the data by name. He will rarely work 
with actual data, and he will never write actual machine instructions. 

This is an important concept. As will be seen in Chapter 4, an electronic system 
has no way of recognizing data and procedures simply by looking at them. They can 
be identified only by their location within storage, and in the Commercial Translator 
system these storage locations are referred to by name. For this reason, Commercial 
Translator nouns will be spoken of hereafter as names. 



Kinds of Names 



Most of the names the programmer will use will fall into one of three general cate- 
gories: data-names, procedure-names, and condition-names. 

Data-Names 

Data-names are names given to the data used in a program. As the programmer will 
see, data-names are assigned to kinds of data, not (except in the case of constants) 
to specific values. Thus, such a name as interest.rate would not refer to a specific 
interest rate, but to a class of data known as interest rates. Technically (although this 
need not concern the programmer), it would name an area in storage in which any 
of several specific interest rates might be placed for some purpose, such as compu- 
tation. 

Data-names may be assigned to single classes of data or to groups of data items. 
For example, the name payroll. record would probably refer to a group of indi- 
vidual items having such names as employee. name, employee.number, hourly. 
rate, and so on. It is important to recognize that, in general, the name refers not to 
any specific value, but only to the kind of data. 
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Data-names are invented and assigned to data at the discretion of the programmer, 
following the rules given below which govern the formation of names. All data 
referred to in the program must be named, but this does not mean that all subdivisions 
of data must be named. For example, if the programmer wishes to refer to a date, he 
will have to give it a name, but he does not have to name the component parts, such 
as the day, the month, or the year, unless he wishes to refer to them individually. 

The general category of data-names may be broken down, for convenience, into 
record-names, field-names, function-names, parameter-names, named constants, and 
so on. The meanings of these names will be explained later in this manual. 

Procedure-Nam es 

Procedure-names are names assigned to individual portions of the program so that 
one procedure can refer to another. Suppose, for instance, that the programmer has 
written a routine for computing a discount and that he wishes to use this routine at 
various times in the program. He could actually copy the routine into the program 
each time it is required, but this may be inefficient. An alternative method would be 
to give the routine a name, such as discount, or discount. calculation; then, when 
the programmer wished to use this routine he could write such an instruction as do 
discount. calculation. As the reader will discover, there are many reasons why 
the programmer may wish to refer from one part of the program to another. Pro- 
cedure-names provide him with the means of doing this. 

Like data-names, procedure-names are invented and assigned by the programmer 
as he needs them, following the rules for name formation given below. They are 
placed at the beginning of the portion of the program to which they apply. 

Procedure-names may be assigned to any sentence or section of the program. (A 
section consists of one or more successive sentences.) The reader will find further 
details of how to use procedure-names in Chapter 3 in the discussion of the com- 
mands do, go to, include, overlap, begin section, and end. Procedure-names 
may also be referred to as sentence-names or section-names, as appropriate. 

Condition-Names 

The concept of condition-names will be more clearly understood after the reader has 
studied the discussion of conditional expressions beginning on page 2 1 of this man- 
ual. In general, however, a condition-name defines a condition which can be used to 
control an operation. 

For example, suppose that a manufacturer has agreed to pay shipping charges for 
goods shipped to customers within 50 miles of the factory, but that charges for ship- 
ment out of this 50-mile zone will be billed to the customer. Obviously, two different 
routines are called for in the program, and the decision as to which will be used will 
depend on the shipping distance. 

Suppose that a code is used in the input records to indicate whether the customer 
is located within the 50-mile zone or not. The programmer will need to refer to this 
code, and it will usually be convenient to be able to give it a name which can be 
written in a procedure statement. 

In this case, the programmer might wish to use the name out.of.zone to indicate 
that a customer is located more than 50 miles from the factory. He can place this 
name in the program by writing an entry that instructs the system that the name is to 
be treated as an equivalent for the code it represents. (The actual method of doing 
this is explained in Chapter 4.) 
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Formation of Names 



Once the condition-name has been defined, the programmer may use it in the 
procedure statements. For example, he might write such a sentence as if out.of.zone 

THEN DO BILLING.ROUTINE.A OTHERWISE DO BILLING.ROUTINE.B. The expression IF 

out.of.zone will cause the system to examine the data to determine if the indicated 
condition has been met. When the reader has studied the discussion of conditional 
expressions, he will realize that a condition-name of this kind is actually a short way 
of writing an expression that shows a relationship between two items. Thus, if the 
"out-of-zone" code were 2, and if the field containing that code were called distance, 
code, the condition-name out.of.zone would actually be equivalent in every way to 
the expression distance. code = 2. 

Condition-names are subject to the general rules for the formation of names, 
which are given below. They may be assigned by the programmer at his discretion. 

Names may be formed by combining any of the characters from the basic list of 
alphabetic characters, numerals, and the period, subject to the following rules: 

1 . Names must not contain blanks . 

2. Names must always begin with an alphabetic character. 

3. They may contain from 1 to 30 characters. 

4. They may neither begin nor end with a period. However, "imbedded" periods 
may be used within the name for the sake of readability. 

5. They may be "qualified" (to make them unique within the program) by the use 
of other names. This is explained below under the heading "Compound Names." 



Compound Names 



In many cases a program will contain duplicate names. This often happens when an 
input file is "updated" to produce an output file, since each file will usually contain 
the same kinds of records. 

Suppose that an input record is named input. master and an output record is 
called output. master. Suppose, further, that each record contains two dates, one 
called order.date, the other called shipment.date. 

If the program involves both kinds of records, it would not be possible to distin- 
guish readily between the two order.date names and the two shipment.date names. 
All four names would be defined in the data description (see Chapter 4), which gives 
the system the information it needs to locate individual items of data. To indicate 
which of the order.date (or shipment.date) names is meant, however, each such 
name can be "qualified," or "compounded," when used in a procedure statement. 
That is, the name of a larger data item of which it is a part can be added to the name 
to identify it. Thus, input. master order.date would be clearly distinguishable from 
output. master order.date. Names qualified in this manner are referred to as 
compound names. 

Compounding of names is not limited to two levels. For example, the various dates 
mentioned in this example may each have an element called month to which the 
programmer may wish to refer individually. If, at the time of reference, the program 
is working with only one record which contains an element called month, there is 
no ambiguity. But should ambiguity exist, the name of a data item at a higher level 
may be used as a qualifier. Thus, the programmer may specify, in this case, order, 
date month or shipment.date month. If, as is likely, both input and output rec- 
ords are in use at the same time, three levels of names may be used in a single 
compound name — for example, input. master order.date month. 

When names are to be compounded, the following rules apply: 

1. Each name must be separated from the next by at least one blank space. (This 
distinguishes between compound and simple names, since simple names may not 
contain blanks.) 
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Placing Names 
in the Program 



2. The names must be written in increasing order from the general to the specific. 
(If the reader is familiar with the concept of level numbers, as discussed in 
Chapter 4 of this manual, he will note that this means that the names must be 
listed in order from the lowest to the highest level number.) 

3. No qualifying names are required that do not contribute to the uniqueness of 
the compound name. Thus, in the example given, if there were only one date 
named in each of the input and output files— e.g., an order.date, but no ship- 
ment. date— it would not be necessary to use the name order.date in forming 
the compound name; the names input.master month and output.master 
month would suffice. 

The organization and structure of data for use in a data processing system is 
further discussed in Chapter 4, entitled "Data Description." The reader is referred, 
in particular, to the discussion of level numbers beginning on page 68. 

The reader has seen that the Commercial Translator system uses names as a con- 
venient—in fact, indispensable— means of identifying data, procedures, and condi- 
tions. It is now necessary to indicate how each name is placed in the program in a way 
that permits the system to connect it with the item to which it refers. 

A Commercial Translator program consists primarily of procedure description and 
data description. The first of these is made up of procedure statements— the actual 
instructions which govern both the processor and the object program. The second 
consists of data description statements— entries which instruct the system to reserve 
a specified amount of storage space for each kind of data and which show the organ- 
ization and nature of the data so that it can be located and used when needed. These 
two sections are discussed in Chapters 3 and 4. 

All statements for a Commercial Translator program must be written in a specified 
format, and, as a guide to the programmer, two columnar forms have been prepared 
for this purpose. One is used for procedure statements, the other for data description 
statements. The first is described in Chapter 3, the second in Chapter 4. 

Procedure-names differ from other names in one important respect. They are used 
as names for sentences and sections (which themselves usually contain names of 
various kinds), whereas data-names and condition-names identify kinds of informa- 
tion. A procedure-name identifies a fixed set of procedure statements. A data-name 
usually identifies a storage area that may contain different values at different times. 

Procedure-names are identified in the procedure description. This is a simple 
matter. It consists merely of writing the procedure-name before the statement or 
statements to which it refers, in accordance with the rules given in Chapter 3. Once 
the name has been written, the program will be able to interpret any reference to 
the name as a reference to the associated procedure statement. 

Data-names and condition-names, however, require amplification. As will be seen 
in Chapter 4, the system must know whether the data is numeric or whether it con- 
tains alphabetic characters. It must know where decimal points, if any, are to be 
placed, where to print dollar signs, and so on. There are a number of such details 
which must be specified. It would have been possible to set up rules for describing 
the data in the procedure description, but this would have been inefficient, since the 
description of each item would have had to be repeated each time its name appeared. 
Since the description is placed in a separate section, however, each name need be 
described only once, regardless of the number of times it is used in the program. 

It follows that each data-name and each condition-name used in the procedure 
description must be properly accounted for in the data description, following the 
rules given in Chapter 4. Once this has been done, the programmer is free to refer 
to the name repeatedly throughout the procedure description. 
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Constants 



It has been emphasized that data-names used in the Commercial Translator system 
generally refer to kinds of data, not to specific values. The actual values represented 
by most data-names are assumed to be variable, and they will either be entered into 
the system as parts of input files when the object program is run or they will be 
computed at some point in the program. 

However, the programmer will often find it useful to be able to place a specific 
fixed value into the program instead of having to read it in as data. For example, if 
a firm allows a discount on its bills, the discount will usually be figured as a fixed 
percentage. The routine for computing the discount, therefore, does not require any 
provisions for inserting varying percentage rates. Thus, it would be convenient to be 
able to write this rate directly into the program. 

Any value — or any group of symbols — which is to be used in the program without 
alteration is called a constant. The programmer will find many uses for numeric con- 
stants, such as the discount rate mentioned, for alphabetic constants, such as names 
and titles to be printed out on final reports, and for alphameric constants, which may 
serve any number of purposes. 

In some circumstances, it will be convenient to write the constant directly in a 
procedure statement. In this case it will be called a literal. In other cases, it will be 
more convenient to give the constant a name and store it within the system so that it 
can be called for by name when required. In this case it will be called a named constant. 

As an aid to the programmer, certain standard constants, such as the value and 
the blank, have been "pre-named." These values are defined in the processor itself, 

.j ^i i _i i„ i ~;.,~„ *,«™ Q o Time tTio nmirrommpr ran writp. these 
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names in the procedure statements without having to define them in the data descrip- 
tion. These special constants, called figurative constants, will be discussed later in 
this section. 

Literals and named constants may be used in procedure statements for the same 
purposes for which data-names are used — that is, as "operands" (i.e., "objects") 
of Commercial Translator verbs. The essential difference between them is that a 
i-x i „„*..„i „„i„o. « „oi<m +~ Uo t-corl "litpriillv" at thp nnint where it 
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is written — whereas a named constant is the name of such a value, and it cannot be 
used, or interpreted, in a procedure statement until it has been defined in the data 
description. 

The following example will show the difference between literals and named con- 
stants: 

Assume that a discount is to be computed by multiplying the amount of an order 
by a discount percentage of two per cent. The programmer might write such a state- 
ment as 

SET DISCOUNT = ORDER.AMOUNT * .02. 

This command would instruct the system to take whatever value was in the field 
called order.amount, multiply it by the value .02, and place the result in the field 
called discount. 

On the other hand, the programmer could place the value .02 in storage, giving 
it a name such as discount. percentage, and then write such a statement as 

SET DISCOUNT = ORDER.AMOUNT * DISCOUNT.PERCENTAGE. 

In this case, the system would take the value in the order.amount field, look up 
the value in the field called discount. percentage, multiply the two values together, 
and store the result, as before, in the discount field. 
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The same result is obtained in either case, and it may appear at first sight that it is 
more efficient to write literals than named constants. This may or may not be so. 
If the constant is short, as in this example, it will usually be more convenient to write 
it as a literal. If it is long, and if it can be given a short name, it may be more efficient 
to treat it as a named constant. Furthermore, the technique of naming a constant 
makes it possible to store large quantities of reference material, such as lists and 
tables, within the system, and to make use of selected items from such a list or table 
as required. The reader will see later how this may be done. 

It should be noted, however, that in certain special cases the name of a named 
constant is implied, rather than actually written. In such a case, the constant will be 
a part of a data item which is named, and it will always be possible to identify it by 
making an appropriate reference to the named item. The reader will see, in the dis- 
cussion of tables, that each individual item in a table need not be named, but the 
table itself (and, often, specific kinds of data within the table) will be named. The 
programmer can then refer to subordinate elements in the table by a kind of indexing 
known as "subscripting." This is explained later in this chapter. 

Literals Although a literal may be written and used in a procedure statement as if it were a 

data-name, it differs from data-names (including named constants) in that its value 
is the value literally stated — it is not used as a name for some other value. 

Rules for Forming Literals 

Literals may be numeric, alphabetic, or alphameric. Some of the rules for forming 
numeric literals differ slightly from the rules for alphabetic and alphameric literals. 
For convenience of reference, the rules governing each type are listed separately. 

Numeric Literals 

1. All literals are limited to 50 characters in length, and, when written on the 
columnar form used for writing procedure statements, they may not be carried 
over from one line to the next. 

2. Numeric literals may contain only numerals, not more than one decimal point, 
and a plus or minus sign to indicate whether the value of the number is positive 
or negative. "Floating point" numbers also contain the letter f, as explained in 
Rule 4 below, and may contain more than one plus or minus sign. The decimal 
point is required except where it would be the last character of the literal; in that 
case it must not be used. The decimal point will be noted by the system in order 
to align the number properly for use, but it will not occupy an actual place in 
storage, and it is not counted in determining the length of the literal. 

3. If the literal is to be operated on arithmetically, it must contain not more than 
20 digits. 

4. Numeric values may be entered as "floating point" numbers by writing the 
"fraction" (i.e., the number or decimal fraction), then the symbol f, and then 
the exponent. The fraction and the exponent may each have a plus or minus sign. 
The symbol f will not occupy a space in storage, and it is not counted in deter- 
mining the length of the literal. The system will accept floating point numbers 
using a base of 10 only. (A floating point number is a number expressed as a 
decimal number or decimal fraction multiplied by some power of 10. For ex- 
ample, the number 1500 might be written as 1.5f3, which is equivalent to 1.5 
times 10 3 ; the same number might also be written as 15f2, .15f4, or in any other 
similar way that is convenient. The number .002, which is equivalent to 2 times 
10 3 , might be written 2f-3.) 

5. Numeric literals must not be enclosed in quotation marks. 
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Named Constants 



Figurative Constants 



Alphabetic and Alphameric Literals 

1 . An alphabetic or alphameric literal may contain any of the characters from the 
basic character set except the quotation mark. A blank is treated as a character 
and may be included in an alphameric literal. 

2. Like numeric literals, alphabetic and alphameric literals are limited to 50 charac- 
ters in length and may not be carried over from one line to another when written 
on the columnar form used for writing procedure statements. 

3. All non-numeric literals must be enclosed in quotation marks to distinguish them 
from names. This rule applies even should the literal contain symbols (such as 
the arithmetic symbols and the blank) which may not be used in names. 

Named constants are placed in the system by specifying them in the data description 
in accordance with the rules given in Chapter 4. Each named constant will usually 
have its own individual name, but in certain cases it may be part of a group of con- 
stants having a group name. As the reader will note from the discussion of tables and 
lists, individual items in a list are often in this category. However, even when the 
individual item does not have a name, it is always referred to by a name of some 
kind, and it may thus be treated in the general category of named constants. 

A named constant may be referred to in procedure statements by writing its name 
as if it were any other data-name (although, of course, it should not be used in a way 
which will change its value) . 

Rules for Forming Named Constants 

Named constants, like literals, may be wholly numeric, wholly alphabetic, or alpha- 
meric. All of the rules specified above for forming literals apply to constants, except 
as follows : 

1 . Named constants are not limited as to length, and when written on the columnar 
form used for data description entries, they may be carried over from one line to 
the next. In this case they are subdivided and written as a series of complete 
constants, one on each line, but at a level lower than that of the name given to the 
total constant. After these Darts have been read into the svstem. the nrocessor 
will reassemble them to form the original constant. 

2. All named constants, including those which are wholly numeric, must be enclosed 
in quotation marks. 

3. Named constants may include any of the characters in the machine's character 
set, including the quotation mark and the blank. (The presence of a blank in an 
otherwise numeric constant makes it alphameric. ) 

The figurative constants resemble named constants except that their names are al- 
ready assigned in the processor itself, so that the programmer need not write data 
description entries for them. 

Figurative constants are names for certain constant quantities which are used fre- 
quently in data processing programs. The list includes names which represent zeros, 
blanks, and the lowest and highest characters in the collating sequence of the machine 
system being used. Following is a list of the figurative constants: 

ZERO or ZEROS 

BLANK or BLANKS 

LOW. VALUE or LOW. VALUES 

HIGH. VALUE or HIGH. VALUES 

In general, a figurative constant is used to place the value it names in a given 
storage area, although it is not limited to this usage. For example, if the programmer 
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wishes to reduce the value of a data item called counter to zero, he can do so by 
writing the instruction move zeros to counter. This procedure will replace all 
previous data in counter by zeros. Similarly, if he wished to erase all data in an 
area called amount, he could write move blanks to amount. In each case, the 
specified area will be completely filled with characters of the value named. 

The names low.value and high. value refer, respectively, to the lowest and 
highest characters in the collating sequence of the system for which the program is 
written. 



Expressions 



Arithmetic Expressions 



The words and symbols of the Commercial Translator language are combined into 
clauses and sentences in order to give instructions to the processor and the object 
program. Before considering the formation of these larger units of the language, 
however, it is important to examine two specialized forms of expression: arithmetic 
expressions and conditional expressions. 

An arithmetic expression is a combination of data-names, conditional expressions, 
and/or literals, joined together by one or more arithmetic operators in such a way 
that the entire expression can be reduced to a single numeric value. (An arithmetic 
operator is a symbol representing addition, subtraction, etc.; a list of operators is 
given below.) Both simple and compound names may be used in an arithmetic 
expression. 

Consider the following examples : 

A + B 

GROSS.PAY - DEDUCTIONS 

GROSS.SALES * COMMISSION 

BEGINNING.ON.HAND + RECEIPTS - SHIPMENTS 

A * (B + C) - (D/E) 

TOTAL.SALES * .3 



In these expressions, the symbols +, — , *, and / are arithmetic operators used 
to express addition, subtraction, multiplication, and division, respectively. They link 
together a variety of terms, including the values represented by the data-names 
a, b, c, gross.pay, deductions, and the literal .3. All of these will represent specific 
values at object time. If the data-name gross.pay, for example, should be 125.50, 
and if deductions should turn out to be 31.20, the expression gross.pay - deduc- 
tions would reduce to a value of 94.30. Similarly, if total. sales should have a 
value of 12,000, the expression total. sales * .3 would reduce to a value of 3,600. 

Arithmetic expressions may be used as components of conditional expressions, 
clauses, and sentences, as will be shown later in this chapter. Use of an arithmetic 
expression will cause a computation to be performed in order to obtain the single 
result to which the expression can be reduced. 

It was stated above that conditional expressions can also be used in arithmetic 
expressions. This is a specialized usage in which a test is made to determine whether 
or not a particular condition is met. The "truth operator" tr is used to indicate this 
test. It is generally used to multiply one or more terms in an arithmetic expression. 
Since it takes on a value of 1 if the conditions of the test are met, and a value of if 
they are not met, it can be used to cancel a term in an arithmetic expression if a 
condition exists in which the term is not wanted. The method for doing this will be 
explained later, in the discussion of "truth functions." 
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The complete list of arithmetic operators and their meanings is given in the fol- 
lowing table : 

Operator Meaning 

+ Addition 

— Subtraction or Negation 

* Multiplication 

/ Division 

Exponentiation 
ABS Absolute Value (i.e., the value of a number treated 

as if the sign were positive) 
TR Truth Value (see the discussion of truth functions) 

Conditional Expressions A conditional expression is an expression which, taken as a whole, may be either 

true or false, depending on conditions existing when the expression is examined. 
Generally, a conditional expression contains at least one variable quantity, and the 
truth or falsity of the expression will depend on the particular value assumed by the 
variable or variables. For example, the expression a is greater than 10 is condi- 
tional, since it may or may not be true, depending on the value of the quantity a. 
Obviously, if a had a value of 12, the expression would be true; if the value were 7, 
the expression would be false. 

A conditional expression may contain data-names, condition-names, arithmetic 
expressions, and expressions which show relationships between values (such as the 
expression is greater than). Conditional expressions may be joined together by 
the words and and or to form compound conditional expressions. 

Conditional expressions may be of either of two principal types: (1) relations, 
and (2) condition-names. 

Relations 

A conditional expression may contain an expression that shows a relationship be- 
tween values. The example given above, a is greater than 10, illustrates the gen- 
eral concept. Six basic relational expressions may be used in conditional expressions, 
each of which may be written in a full form or in an abbreviated form. They are as 
follows : 

IS GREATER THAN 

IS NOT GREATER THAN 

IS EQUAL TO 

IS NOT EQUAL TO 

IS LESS THAN 

IS NOT LESS THAN 

These expressions may be used to connect data-names, literals, and arithmetic 
expressions. The following examples indicate typical uses of the relational ex- 
pressions: 

BEGINNING.ON.HAND + RECEIPTS - SHIPMENTS IS 

LESS THAN REORDER.POINT 
AGE GT 21 

A * (B + C) - (D/E) = 500 
DEPENDENTS NOT = 
A GT B OR A = C 
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or 


GT 


or 


NOT GT 


or 


= 


or 


NOT = 


or 


LT 


or 


NOT LT 



Condition-Names 

In many cases, a record can be processed in one of several ways, depending on cer- 
tain characteristics of the record or the existence of a particular condition at the time 
it is processed. For example, assume that a company is using a file of personnel 
records to prepare a report on employees' dependency status. The records of single 
employees will probably be processed in a different manner from those of married 
employees. It might also be essential to distinguish between married and divorced 
employees. Thus, each record must be examined individually to determine marital 
status. Marital status would normally be indicated by a code of some kind, and, for 
the purposes of this illustration, it will be supposed that the initials m, s, and d indi- 
cate the classifications (i.e., the "conditions") "married," "single," and "divorced," 
respectively. 

One of these initials will appear in each record, and the programmer must reserve 
a place in storage for this code by giving a general name to the area in which the 
code is to be placed. This is done by writing an entry in the data description, as 
explained in Chapter 4. (See, in particular, the discussion beginning on page 71, 
in which the reader is shown how a data description for this example may be written. ) 
Assume that the general name used is marital. status. This is a data-name, and it 
may be used in procedure statements in any of the ways in which data-names may 
be used. However, in this case, it is desired to name, in addition, the specific values 
which this data-name represents. Specifically, the programmer will wish to be able to 
refer to the initials M, s, and d. 

If he wishes, he may write a relational expression such as has been shown above. 
Thus, marital. status = 'm' is a relational expression, and it may be used in such 
an instruction as if marital. status = 'm' then do tabulation. routine.a. (Note, 
incidentally, that the initial m is placed in quotation marks to show that it is a literal, 
for this code will appear literally in the record. ) 

However, it is often simpler to treat the appearance of a particular code in the 
assigned area as a condition; this condition can then be given a condition-name 
which signifies that the condition is present. The condition-name married, for ex- 
ample, could then be used to indicate the presence of the initial m. Condition-names 
are assigned in the data description, and the reader is referred again to Chapter 4 to 
see how this may be done. 

Once a condition-name has been defined, it may be used directly in procedure 
statements. The condition-name actually serves as an abbreviation of a relational 
expression. In this example, the condition-name married is exactly equivalent to 
marital. status = 'm' and it may be substituted for it wherever the programmer 
wishes. The instruction mentioned above (if marital.status = 'm' then do tabu- 
lation. routine.a) can then be reduced to if married then do tabulation, 
routine.a. 

Similarly, all of the other conditions which the field marital.status can assume 
are defined in the data description and given condition-names, assuming the pro- 
grammer has need of them. (If the programmer needs to refer only to the condition 
married, he need not assign condition-names to the other conditions. ) 

The reader should note that the condition-name itself is a conditional expression 
in the full meaning of that term. It may be used in clauses and sentences in the same 
manner as any other conditional expression. The most general use of a condition- 
name is in a clause of the if . . . then type, such as if married then, or if single 
then. This construction will be explained in the discussion of conditional clauses 
later in this chapter. 
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AND, OR, and NOT 

The Commercial Translator system is fully capable of interpreting and processing 
"compound conditions" — i.e., conditional expressions which are themselves com- 
posed of two or more conditional expressions. 

Suppose the following expressions are being used as conditions: 

MARRIED 

OVER.21 

HOURLY.RATE IS GREATER THAN 3.50 

HOURLY.RATE IS LESS THAN 5.00 

These expressions may be joined in any combination the programmer might wish, 
using the words and and/or or. In some cases, it will also be necessary to enclose 
one or more pairs of conditions in parentheses. The negative form of a conditional 
expression may also be used; this is obtained by placing the word not before the 
expression. 

The interpretation of conditional expressions is governed by four rules: 

1. The word or is interpreted as "either or both." In other words, it is used in the 
"inclusive" sense employed in formal logic. 

2. The word and is interpreted as "both." Simple conditions joined by and must 
both be true in order for the compound condition to be true. 

3. Each conditional expression must be completely stated. For example, the system 
would not accept such an expression as hourly.rate is greater than 3.50 and 
less than 5.00. To convey the intended meaning, the full expression must be 
written as hourly.rate is greater than 3.50 and hourly.rate is less than 
5.00. 

4. When a compound conditional expression contains both the word or and the 
word and, it will be interpreted as if the terms connected by and were enclosed 
in parentheses. In other words, each pair of conditions joined by the word and 

will be considered as a single nnnHitinn whirh ic trnp if hnth nf th<* cnKnrrli'npto 

conditions have been met. If a contrary sense is intended, parentheses must be 
used to show it. 

The following examples should clarify the interpretation of these rules: 

Compound 
Conditional Expression Interpretation 



MARRIED AND OVER.21 Both of the conditions married and over.21 

must be met. 

MARRIED OR NOT OVER.21 Either the condition married or the condition 

not over.21, or both, must be met. 

NOT MARRIED AND Both of the conditions not married and 

HOURLY.RATE IS NOT hourly.rate is not less than 5.00 must be 

LESS THAN 5.00 met. 

MARRIED OR OVER.21 AND Either the condition married must be met or 
HOURLY.RATE IS GREATER the combination over.21 and hourly.rate 
THAN 3.50 is greater than 3.50 must be met, or both. 
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Compound 
Conditional Expression 



Interpretation 



(MARRIED OR OVER.21) 
AND HOURLY.RATE IS 
GREATER THAN 3.50 



MARRIED AND OVER.21 
AND HOURLY.RATE IS 
GREATER THAN 3.50 

MARRIED OR OVER.21 OR 
HOURLY.RATE IS GREATER 
THAN 3.50 



Either the condition married or the condition 
over.21 must be mei, or both, and, in addi- 
tion, the condition hourly.rate is greater 
than 3.50 must also be met. 

All three conditions must be met. 



The compound condition will be met if any 
one of the three conditions, or any two, or all 
three conditions, are met. 



Truth Functions 



It has been pointed out that conditional expressions may be used in arithmetic ex- 
pressions in connection with the "truth operator" tr. When the truth operator is 
used, as explained below, it converts the conditional expression into an arithmetic 
expression having a value of either 1 or 0. This value can then be used normally in 
the arithmetic expression. 

The conditional expression is placed in parentheses and the operator tr is placed 
immediately in front of it. The resulting term is called a truth junction. The truth 
operator signals to the system that it must make a test to determine the truth or 
falsity of the conditional expression. If the condition is found to be true, the truth 
function as a whole is automatically assigned a value of 1 ; if the condition is false, 
the truth function is given a value of 0. 

Suppose that a manufacturer agrees to give a discount of five per cent on bills for 
purchases of more than one thousand dollars. If the amount of the purchase is to be 
found in a field called order.amount, the programmer could write such a state- 
ment as: 

SET DISCOUNT = ORDER.AMOUNT * .05 * TR 
(ORDER.AMOUNT IS GREATER THAN 1000). 

The conditional expression order.amount is greater than 1000 will then be 
examined. If it is found to be true, the whole truth function will be replaced by a 
value of 1 ; in this case the discount would be computed as five per cent of the value 
in the order, amount field. If the conditional expression is found to be false, the 
truth function will be given a value of 0, and the net effect would be to cause the 
discount to be computed as 0. 

The truth operator may be used with relational expressions, as in the example 
given, or with condition-names. 



Clauses 



The basic components of the Commercial Translator language have now been dis- 
cussed. The remainder of this chapter will show how these components can be com- 
bined to express meanings. 

The basic complete unit of meaning in the Commercial Translator language is the 
sentence. Sentences, however, are composed of one or more shorter units, known as 
clauses. There are two kinds of clauses: imperative and conditional. 
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Imperative Clauses 



Conditional Clauses 



An imperative clause is a group of words that expresses a complete command. The 
clause may or may not include symbols. It always begins with a verb and may con- 
tain one or more operands of the verb, as appropriate. The operands may include 
data-names, procedure-names, condition-names, literals, figurative constants, and 
arithmetic expressions. Following are several examples of imperative clauses: 

OPEN INPUT.MASTER.FILE 

GET PAY.RECORD 

ADD 1 TO COUNTER 

MOVE ZEROS TO AMOUNT. FIELD 

GO TO TAX.CALCULATION 

SET NET.PAY = GROSS.PAY - (GROSS.PAY 

- (EXEMPTIONS * 13)) * .18 - OTHER.DEDUCTIONS 

A conditional clause consists of a conditional expression introduced by the word if 
and terminated by the word then. The conditional expression may be simple or 
compound. The word if is an operator which informs the system that the condi- 
tional expression which follows must be tested for truth or falsity. The word then 
defines the limit of the conditional expression to be tested; it will always be followed 
by an imperative clause. 

Following are several examples of conditional clauses: 

IF OUT.OF.ZONE THEN 

IF AMOUNT GT 200 THEN 

IF MARRIED AND OVER.21 THEN 

IF A = B OR A = C AND A GT D THEN 



Sentences 



A Commercial Translator sentence corresponds to a sentence in English — it ex- 
presses a complete and independent thought. It must contain at least one imperative 
clause and may contain, in addition, one conditional clause and one or more addi- 
tional imperative clauses. It is terminated by a period, which must be followed by a 
blank to distinguish it from the "imbedded period" used in names and from the decimal 
point used in numeric literals. Imperative clauses within the same sentence must be 
separated by commas. 

When a conditional clause is used in a sentence, it must begin the sentence, and 
it must be followed by one or more imperative clauses to be executed if the pre- 
scribed condition is met. If the programmer wishes to prescribe alternative action to 
be taken if the conditional expression proves false, he may specify it by writing next 
(without intervening punctuation) the word otherwise, followed by one or more 
imperative clauses. If the conditional expression should prove false, and if the 
sentence does not contain the word otherwise, the conditional sentence will cause 
no action and the system will proceed to the next sentence in the program. 

The following examples show how Commercial Translator sentences may be 
constructed: 

ADD 1 TO COUNTER. 

GO TO TAX.CALCULATION. 

STOP. 

IF MARRIED THEN MOVE NAME TO MAILING.LIST.M, 

ADD 1 TO COUNTER. 
IF GROSS.PAY LT NET.PAY THEN GO TO ERROR.ROUTINE. 
IF OUT.OF.ZONE THEN DO BILLING.ROUTINE.A OTHERWISE 

DO BILLING. ROUTINE.B. 
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Sentences may be assigned procedure-names, so that the programmer can make 
reference to them in other parts of the program. It will be seen that this provision 
makes it possible to carry out any sequence in the program whenever it is desired, 
without having to rewrite it each time. Suppose, for instance, that the last sample 
sentence given above, which begins if out.of.zone . . ., had been given the name 
distance. check. Whenever the programmer wishes to make this check and take 
appropriate action, he can instruct the program to "transfer" to this sentence by 
writing either do distance. check or go to distance.check. (This will be explained 
more fully in Chapter 3.) The actual method of assigning names will be discussed in 
Chapter 3 under the description of the columnar form used in writing procedure 
statements. 



Sections 



Divisions 



A section consists of one sentence, or a group of successive sentences, which has 
been given a name for reference purposes in accordance with the rules given below. 

At first sight, it may appear that a Commercial Translator section corresponds 
closely to a paragraph of English. However, there are several distinctions. Sentences 
are not grouped into sections for the purpose of clarifying the logic or the structure 
of the program for the benefit of the system, whereas paragraphing in English does 
perform such a service for the reader. Sectioning, in the Commercial Translator, is 
used for the purpose of naming portions of procedure. 

For example, suppose the programmer has written a sequence of sentences to cal- 
culate compound interest. Instead of having to write out this sequence each time 
the calculation is required, he can group the sentences into a section and give it a 
name by which it can be referred to elsewhere in the program. If this name were 
interest.routine, for instance, he could write such a clause as do interest, 
routine at any point in the program, and this instruction would cause, first, a trans- 
fer to that routine and, second, a transfer back to the original point when the routine 
has been carried out. (Details will be found in the discussion of the do command in 
Chapter 3.) Grouping of sentences into sections, then, is a device for identifying such 
a group for further reference. 

The beginning of a section must be identified by a procedure-name, followed by a 
period. The name must then be followed by the words begin section, in accordance 
with the rules for using that verb, as given in Chapter 3. Following the last sentence 
in the routine, the programmer must write the word end, followed by the procedure- 
name used originally to identify the section. 

Sections may be "nested," that is, one or more sections may be contained within 
a larger section, but each such section must be wholly contained — it cannot overlap 
another section. 

Where necessary, the names of sections can be used as parts of compound names. 



All Commercial Translator programs are composed of three divisions, the Procedure 
Description, the Data Description, and the Environment Description. The first of 
these contains the procedure statements of which the program is composed. The 
second provides the processor with information about the data to be used in the 
object program. The third is used to make certain technical connections between the 
program and the machine system on which it will be run; these details are dependent 
on the particular system and are therefore discussed in the publications covering the 
processors for the various systems. 
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It is not necessary that these three divisions appear as separate entities. If ap- 
propriate, the programmer may write a portion of one, then a portion of another, 
and so on. However, each such portion must be properly labeled with a division 
header. Each header consists of the name of the division, preceded by an asterisk. 
The three division headers are : 

^PROCEDURE 

*DATA 

^ENVIRONMENT 

These names are written, where required, in the "name margin" of the form used 
for the procedure description, as explained in Chapter 3, or in the name columns of 
the form used for the data description, as explained in Chapter 4. In other words, 
the asterisk always appears in the left-most name column, followed immediately by 
the remainder of the header. 

All entries following a division header are assumed to be a part of the specified 
division. 



Punctuation and Spacing 



The punctuation of Commercial Translator sentences is reasonably simple and, for 
the most part, self-evident. It may be summarized in the following rules: 

1. All words are separated by blanks, or by any character which cannot legally 
be used in a word, such as an arithmetic operator. (See the rules for forming 
names, beginning on page 15.) 

2. Multiple blanks are treated as single blanks, except within alphameric literals, 
where each blank will be treated as a separate character. (Numeric literals can- 
not contain any blanks.) 

3. Each sentence must be terminated by a period, followed by a blank. Should the 
blank be omitted, the period will be treated as an "imbedded period," except 
where the period is found in Column 72 of the procedure description form. 

4. The "imbedded period" — i.e., a period surrounded by non-blank characters — 
serves one of two functions, depending on the context: (1) If it appears in a 
"word" consisting wholly of numerals, or in a floating point number, it will be 
treated as a decimal point. (2) In any other context (except within a literal), it 
will serve as the equivalent of a hyphen — in other words, as the means of con- 
necting separate parts of a simple name. 

5. Successive imperative clauses in a sentence must be separated by single commas; 
for the sake of clarity, the programmer may use blanks in addition, but they 
will be ignored. 

6. Arithmetic operators may be used with or without surrounding blanks. Blanks 
may be used for the sake of clarity, as in the expression A + B * C, but they 
will be ignored; this expression could therefore be written A + B*C. However, 
the programmer must not write two successive arithmetic operators unless the 
second of them is either the operator tr or the operator abs. Where the effect 
of two successive operators is required, one term may be enclosed in paren- 
theses; thus, while the expression A * -B is illegal, the same value may be 
written A * ( — B), The minus sign in this case could have been followed by a 
blank, but the notation given is customary. 
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7. The rules of punctuation and spacing do not apply within literals, which may 
contain any character except the quotation mark, or within constants defined in 
the data description, which may contain any character. Alphabetic and alpha- 
meric literals, and all named constants, must be enclosed in quotation marks. 
(See the rules governing literals and named constants, beginning on page 18.) 

8. Floating point numbers are written as numeric literals. (See the discussion of 
numeric literals, beginning on page 18, and also the rules for writing floating 
point numbers in the data description, on page 80.) 

9. Parentheses must be used to group together two or more terms which are to be 
acted on by a single arithmetic operator, in accordance with the rule that all 
operators act on the next named item, or the next parenthetical expression, 
following the operator. 

10. Subscripts must be enclosed in parentheses, and if more than one subscript is 
used within the same parentheses, they must be separated by single commas. 
(See the discussion of lists, tables, and subscripts beginning below.) 

11. Parentheses may be used wherever needed in arithmetic expressions and in 
compound conditional expressions for the sake of clarity; where ambiguity 
would result from their omission, they must be used. 

12. Division headers must begin with single asterisks. 

13. Punctuation and spacing associated with any particular verb will be found in the 
general format prescribed for the verb in Chapter 3. 

14. When it is necessary to carry over an item from one line to another on either 
the procedure description or data description forms, selection of the "break 
point" must follow the rules given for those forms. In general, it should also be 
understood that a blank is assumed to follow Column 72 of the procedure 
description form and Column 71 of the data description form. 

15. When a function is named as an operand in a procedure statement, the names 
of the data to be substituted for the parameters must be placed in double 
parentheses immediately following the function-name. These data-names must 
be separated by single commas. (See the discussion of functions beginning on 
page 32.) 



Lists, Tables, and Subscripts 



Just as a clerk may use a reference table to obtain data, the programmer can direct 
the program to look up data in a list or table stored within the data processing system. 
The programmer must therefore know how to place the table in storage initially and 
how to write instructions for locating data in it. 

A list, or table, may be regarded as an ordered grouping of data. The actual data 
may be either fixed or variable, depending on the need. If it is fixed, it is usually 
entered into the system as a series of constants; if it is variable, it will be either 
placed in the system when the input records are read in or produced as a result of 
some operation performed within the system. 

In either case, it is necessary to establish the format of the table in such a way that 
the system can locate individual items of data within it. Thus, placing a table in the 
system requires two steps : ( 1 ) establishing the structure and format of the table, and 
(2) making provisions to enter the required data in that structure. When this is done 
properly, the programmer may call for any item of data in the table as required. 

28 



The actual methods of storing a table for use are described in Chapter 4, since 
data description entries are required. To illustrate the general principles involved 
in preparing and using a table, however, the following example may be helpful: 

Suppose that the programmer wishes to be able to refer to a table of passenger 
transportation rates and that the general form of this table can be represented by the 
following excerpt: 

City One-Way Round Trip Excursion 



Los Angeles 153.42 285.16 212.87 

Miami 78.60 141.63 118.92 



When a table of this kind appears on a printed page, it is seen to have a grid-like 
structure, consisting of vertical columns intersected by horizontal lines. Such a struc- 
ture cannot be placed in storage in this form, since data is fed into the system in a 
continuous stream. However, the table can be read line by line, one line succeeding 
another, until the entire table has been placed in the system in the form of a long 
list of data. In fact, several tables of the same type can be entered into the system in 
succession, as if they made up a single "three-dimensional" table. Thus, in the ex- 
ample given, there might be one rate table for the vacation season, another for the 
"off season," and so on. The two- or three-dimensional structure of the table is 
preserved by the use of "level numbers," as explained in Chapter 4, but the total 
mass of data would appear in storage as one long "string" of data. 

It follows that a simple list of items may be thought of as a one-column table, or 
that a table, no matter how complex, may be thought of as a special form of list. In 
the example given, an essentially two-dimensional table has been reduced to a list, 
called rate. table, consisting of, say, 30 lines, each called rate, and each contain- 
ing the four items city, one. way, round.trip, and excursion; these data-names 
correspond to the column titles in the example. 

In this form, the data is not usable until some means has been established for lo- 
cating each individual item. This is done initially by arranging the data so that each 
line consists of exactly the same number of character spaces, with each item in the 
line occupying a position that corresponds exactly to the position of the correspond- 
ing item in each other line. Each item can then be located by its position in storage, 
which, as has been pointed out, is the basic principle by which all data in storage is 
located. 

It is then necessary to find a way of identifying each position and each line so that 
any particular item can be located. A method for doing this is explained in Chapter 4, 
in connection with the sample table previously mentioned. The actual method used 
depends on the principle of counting. Continuing with the example given, suppose 
Miami is the 17th city listed in the table. If the programmer wished to obtain the 
one-way rate for Miami, he would have to find a way of indicating to the system that 
it must find the 17th line of the table and then locate the second entry on that line. 
Obviously, there must be some means of relating the name Miami to the number 17. 

This may be done in several ways. In most data processing operations, the normal 
way would be to show the relation externally by writing a series of code numbers 
corresponding to the names. Only the code numbers themselves would enter the 
system. For the counting principle to operate correctly, the numbers would have to 
be assigned sequentially and in the same order as the corresponding lines of data in 
the table. 
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These code numbers would then be used in the input records in lieu of the actual 
names. Naturally, they would have to be placed in a field reserved for them, so that 
they could be properly identified. Suppose that in this case the field were called 
destination. If the programmer then wrote a procedure statement containing the 
data-name destination, the system would look at that field to see what number it 
contained. This number could then be used as a means of referring to the table. 

Subscripts Numbers or names used to locate items in a list or a table are known as subscripts. 

In order to use them, the programmer must place them within parentheses following 
the data-name showing the kind of data being sought. Thus, since the table of this 
example contains a data sequence called rate, the instruction move rate (desti- 
nation) to list. a would cause the system to obtain the number in the destination 
field, use this number to locate the corresponding line of the table, and move the 
entire contents of the line to the area called list.a. In this case, the data moved 
would include all items contained on that line, including city, one.way, round.trip, 
and excursion. 

Often, however, only one of these items would be required. As will be seen in 
Chapter 4, the data description entries used to place the table in storage permit the 
programmer to locate individual items on each line. If these entries have been prop- 
erly made, the programmer can write such a statement as move one.way (destina- 
tion) to bill.amount, and the system would then locate the line having the number 
indicated in the destination field, single out the particular part of the line called 
one.way, and move that one item to the area called bill.amount. 

It is conceivable that the programmer might wish to specify that the system obtain 
a rate for a particular city, rather than the rate for whatever city happened to be 
indicated in the destination field. Once again, correspondence between the name 
and the number would have to be established. This could be achieved by writing a 
data description entry in which the name of the city was specified as the name of a 
literal number. Thus, miami might be specified as the name of the constant value '17'. 
Then, if the programmer wrote move rate (miami) to list.a or move one.way 
(miami) to bill.amount, the system would recognize that the name miami was 
equivalent to the number 17 and would use that number as a means of referring to 
the table. 

It has been shown how a single subscript may be used to identify an item in a table. 
Actually, as many as three subscripts may be used within the same pair of parenthe- 
ses. To take a simple example, suppose that the contents of a book had been stored 
within the system and that the programmer wished to make reference to a particular 
word in a particular line on a particular page of the book. Suppose, further, that the 
data-names word, line, and page had been properly entered in the data description 
in such a way that entries called word were subordinate to entries called line, which, 
in turn, were subordinate to entries called page. (As Chapter 4 explains, level num- 
bers are used for this purpose. ) 

To specify the 4th word in line 10 of page 150, the programmer could then write 
either page (150) line (10) word (4) or page line word (150, 10, 4). These 
two expressions are equivalent. In the first case, each data-name is subscripted indi- 
vidually. In the second case, it is the name word which is subscripted, but this name 
has been compounded by the use of the names of two higher levels, page and line, 
to make it unique. If the name word had been unique in the program — i.e., had not 
been used outside of this particular sequence — the desired item could be indicated 
simply as word (150, 10, 4). 

When more than one subscript is included within the same pair of parentheses, 
they must be separated by single commas. The number of subscripts used must cor- 
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respond to the number of subdivisions — i.e., the number of "levels" — of the table 
required to obtain the item. For example, if the programmer wished to obtain all of 
the words on line 10, it would be sufficient to write either page (150) line (10) or 
page line (150, 10). If the name line were unique, it would suffice to write line 
(150,10). 

A subscript may consist of a single name representing a variable quantity (such 
as a data-name) , or a literal, or it may consist of an arithmetic expression of the form 

a * VARIABLE ± b 

in which the quantities a and b are literals and the name variable is the name of a 
field which may contain a variable quantity. This name may be a compound name, 
but, whether simple or compound, it must not have a subscript. Condition-names 
may not be used in subscripts. A name, literal, or arithmetic expression used as a 
subscript must represent a positive integral value. 

Following are examples of subscripted names: 

Subscripted Name Comment 



PAGE LINE WORD (150, 10, 4) 



The subscripts actually apply to the name 
word, but it is assumed that this name is not 
unique and has been compounded by the 
use of the names page and line. 



WORD (150, 10, 4) 



RATE.TABLE ONE.WAY 
(2, DESTINATION, 4) 



ITEM (BASE - 1) 



ITEM (4 * AMOUNT) 



The name word is assumed to be unique, but 
it is part of a larger structure having three 
levels which must be identified by subscripts. 

It is assumed that there are several different 
tables called rate. table, each having the 
same structure. The 2 indicates the second 
table of this series, the name destination 
is the name of a field in the table, and the 
code 4 is a literal code which identifies a 
further subdivision of the table — e.g., "fam- 
ily plan, 4 persons." 

This subscript obtains the value following the 
one obtained by the notation item (base). 
This construction may be useful in such pro- 
cedures as interpolating between successive 
items in a table. Usually (in this particular 
kind of procedure ) both items would be ob- 
tained and both would be used as inputs to 
some interpolating procedure. 

In this case, the value of amount would be 
obtained and it would then be multiplied by 
the factor 4 and used as the subscript. Such 
a subscript could be used to obtain every 
fourth value in a table, assuming the value 
in the amount field is increased by 1 on 
each repetition of the routine. 
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Functions 



While the term "function" is often associated with mathematics, the concept has 
certain general applications that can greatly simplify the writing of programs. Accord- 
ingly, the Commercial Translator system has been designed to handle certain kinds 
of functions as an added convenience to the programmer. 

The term function is used in the Commercial Translator to mean a result obtained 
as a consequence of some procedure. More precisely, it means a result obtained from 
a procedure specified by a begin section command, and, in particular, it is a result 
named in the giving clause of that command. 

For example, in the command begin section using a, b, c giving minimum, the 
name minimum is a function-name. This name refers to a field in storage which will 
contain the function after the procedure specified by this command has been carried 
out. (A hypothetical procedure of this type will be described and explained pres- 
ently.) 

The reader will note that this command also contains a clause beginning with the 
word using and that three data-names (a, b, and c) have been specified in that 
clause. These names represent data which will be used in obtaining the function. The 
three items of data are called parameters, and the three names are parameter-names. 
The term "parameter" is limited, in the Commercial Translator system, to data 
named in the using clause of the begin section command. 

Each of these names — the function-name and the three parameter-names — identi- 
fies a field in storage. At object time the three parameter fields will contain data to 
be used in the procedure, and the rules governing the do command (which causes 
the procedure to be executed) provide a means by which the data will be placed 
automatically in those fields. 

To illustrate the use of functions and parameters, a sample procedure will be 
examined in detail. Suppose that the programmer wishes to determine which of three 
values is the lowest, so that he can use it elsewhere in the program. Suppose, further, 
that he wishes to be able to compare values of different kinds and therefore wishes 
to use a procedure that can be used with data from a variety of sources. For this 
purpose he has written a procedure called minimum.routine, which consists of the 
following procedure statements: 

MINIMUM.ROUTINE. BEGIN SECTION USING A, B, C GIVING MINI- 
MUM. 

IF A IS LESS THAN B THEN MOVE A TO MINIMUM OTHERWISE 
MOVE B TO MINIMUM. 

IF C IS LESS THAN MINIMUM THEN MOVE C TO MINIMUM. 

END MINIMUM.ROUTINE. 

The name minimum.routine identifies this procedure so that the programmer 
can refer to it elsewhere in the program. For purposes of illustration, it will be as- 
sumed that the programmer has written the following command later in the program: 

DO MINIMUM.ROUTINE USING D, E, F GIVING MINIMUM.2. 

It is important to see precisely what happens in this case. First of all, when the 
processor encounters the minimum.routine section as it is originally written, it will 
note the three parameter-names (a, b and c) and the function-name (minimum). 
It will examine the entries written for those names in the data description (which 
will be discussed in Chapter 4) and will obtain information about the amount of 
storage space to be reserved for each, together with certain other technical details. 
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The net effect will be that space in storage is reserved for the actual data to be used 
and the actual result to be obtained. The values themselves will be obtained at object 
time when the program encounters the do minimum.routine command. 

The reader will have noted that this do minimum.routine command, like the 
begin section command, contains using and giving clauses. These clauses name 
the values to be used in the minimum.routine procedure and the result to be pro- 
duced. When the system encounters this command at object time, it will act as follows : 

First, it will examine the field specified by the first data-name (d). It will obtain 
the value found there and move it to the first field named in the begin section com- 
mand — i.e., field a. It will then obtain the value in field e and move it to field b. Sim- 
ilarly, it will move the value found in field f to field c. This process of data substitu- 
tion follows the rule that items of data named in a do command will be placed in the 
parameter fields named in the begin section command in the order in which they 
are named. 

Once the actual data has been placed in the parameter fields, the minimum.rou- 
tine procedure will be carried out, using the data which has now been placed in the 
parameter fields. If fields d, e, and f had originally contained values of 11, 7, and 8, 
respectively, field a will now have a value of 11, field b a value of 7, and field c a 
value of 8. The procedure will then operate as follows: (1) The system will examine 
fields a and b, obtain the values they contain, and compare them. Since in this case 
the value of b is smaller, it will be moved to the field called minimum. (2) The sys- 
tem will then examine field c and the minimum field, note the values contained in 
them, and compare them. In this case, the value in the minimum field is the lower. 
Thus, since the condition if c is less than minimum has not been met, the instruc- 
tion move c to minimum will be ignored. (The lowest of the three values, of course, 
is already stored in the minimum field.) (3) The system will then note the name of 
any field specified in the giving clause of the do command. In this case, there is such 
a name, and it is different from the function-name given in the begin section com- 
mand. In such a case, the value in the latter will be moved to the former. Thus, the 
value 7 will now be placed in the minimum. 2 field. (4) The command end mini- 
mum.routine defines the end of the procedure, and the system will then return to 
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The reader will see, thus, that the effect of the using and giving clauses in the do 
command is to cause a series of data movements. Prior to the execution of the pro- 
cedure, data named in the using clause of the do command will be moved to the 
parameter fields named in the using clause of the begin section command. After 
the procedure has been carried out, the results will be moved from the function fields 
named in the giving clause of the begin section command to the data fields named 
in the giving clause of the do command. 

It is not necessary to employ the using clause each time a do command is written, 
if the programmer wishes to use the values already placed in the parameter fields. 
However, since the procedure will operate with whatever values are found in the 
parameter fields, the programmer must be sure that no unintended values are left 
there. In some cases, it may be useful to place "high values," "low values," blanks, 
or zeros, in a field; the figurative constants, thus, can be used as data-names. 

Similarly, the giving clause need not be written in a do command if the program- 
mer intends to refer to the result (or results) as placed in the function field (or fields) 
named originally in the begin section command. 

As the reader has seen, the use of the begin section and do commands makes it 
possible to set up basic procedures and to use them with many different kinds of 
data. If the procedure is properly specified by the use of a begin section command, 
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the programmer may use this procedure for any number of subsequent operations, 
using data from different fields. The minimum.routine procedure used in this 
example might be used in such different ways as the following: 

DO MINIMUM.ROUTINE USING CALCULATED.PRICE, 
MARKET-PRICE, HIGH. VALUES GIVING PRICE. 

DO MINIMUM.ROUTINE USING RAIL.EXPRESS, AIRFREIGHT, 
PARCEL.POST GIVING SHIPPING.RATE. 

DO MINIMUM.ROUTINE USING FLAT.RATE, QUANTITY.RATE, 
HIGH. VALUES GIVING RATE. 

Note the use of the figurative constant high.values as a data-name in two of these 
examples. In these cases the figurative constant would cause the highest values in 
the machine's collating sequence to be placed in the indicated parameter field. Since 
the programmer is concerned with choosing the lower of two values, this procedure 
assures that no unwanted lower value is found in the third parameter field. 

Use of Functions The reader has now seen how the same procedure may be used to obtain different 

in Procedure Statements results by processing different data obtained from different fields. The result (i.e., 

the function) will always be located in a specified field, and thus it may be obtained 
for use in other procedures. In other words, the function-names of the begin section 
command may be used like any other data-names, once the procedure has been 
performed. 

However, a still shorter method is available. Instead of having to write a do com- 
mand which orders a procedure to be carried out, the programmer may write the 
name of a function directly in a procedure statement, together with the names of the 
data items to be substituted for the parameters, and the system will carry out the 
begin section procedure just as if the do command had been written. In order to 
achieve this result, the programmer must specify the data to be used by placing the 
data-names in double parentheses immediately after the function-name. These names 
must be separated by single commas. 

When this technique is used, the function-name itself must be specified. Since no 
do command is used, there is no way of directing that the function be moved from 
the function field to another field; thus, it can be obtained only from the former. 

Referring once again to the example of the minimum.routine and to the three 
examples above, the programmer could write such statements as the following: 

MOVE MINIMUM ((CALCULATED.PRICE, MARKET-PRICE. 
HIGH.VALUES)) TO PRICE.LIST. 

SET SHIPPING.COST = MINIMUM ((RAIL.EXPRESS, AIRFREIGHT, 
PARCEL.POST)) * QUANTITY. 

SET RATE.FACTOR = MINIMUM ((FLAT.RATE, QUANTITY.RATE, 
HIGH.VALUES)) * 1.15. 

All function-names and all parameter-names used in the program must be written 
in the data description, as explained in Chapter 4. In particular, they must be identi- 
fied by the type codes funct or param, as appropriate, and they must be described 
in accordance with the rules governing data description entries. 
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Procedure Description 



Introduction 



This chapter is concerned with the verbs and commands which are presently a part 
of the procedure vocabulary of the Commercial Translator language. The verbs 
fall into two main categories. Most of them are used in commands that state the 
data processing steps to be performed, anu tuus they are called program verbs. 
The other category includes the "processor" verbs; these verbs are used in the 
processor-directing commands. 



Verbs 



The list of verbs is given below. The organization of this chapter is based on the 
classification shown in the list: 



Program Verbs 



OPEN 
GET 
FILE 
CLOSE 



Input/Output 



MOVE 



Data Transmission 



SET 
ADD 

GO TO 

DO 

STOP 

LOAD 



Arithmetic 



Control 



Miscellaneous 



Processor Verbs 

OVERLAP 

BEGIN SECTION 

END 

INCLUDE 

CALL 

NOTE 

ENTER 

The Commercial Translator system is designed as an "open-ended" programming 
system. That is, the list of verbs and associated commands is never closed. The 
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mands when required. 



Commands 



Most of the discussion in this chapter is concerned with commands. Each verb in 
the preceding list forms the basis for a particular type of command; accordingly, the 
various commands can be classified as either program commands or processor com- 
mands. A command normally consists of a verb followed by one or more operands 
and may be written as an imperative clause or as a sentence. 
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Format of 

Procedure Statements 



The clauses, sentences and sections that constitute the procedural portion of a 
Commercial Translator source program are written in "free-form" text on a pro- 
gramming form designed for that purpose. The form is shown on page 36; it has 
just four fields, which are as follows : 



Ctl. and Serial 
(Col. 1-6) 



Though separated on the form, the six spaces of "Ctl." and "Serial" are actually 
one field; the information entered in the first three spaces is the same for all lines 
on one page. This area of the form is used to indicate card sequence by means of 



numoers and/ or aipnao 
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by the processor. (Source programs are read by the processor in the form of a deck 
of punched cards or their equivalent on tape; each line of the programming form 
becomes one card in the source program deck.) The right-most space of this field, 
i.e., Column 6, is usually left blank or else made zero so that subsequent inserts can 
be numbered sequentially. For example, if the serials on a page are 010, 020, 030, 
etc., cards numbered 011, 012, . . . 019 can be inserted later between 010 and 020. 



Procedure Name 
(Col. 7-12) 



Columns 7-12 of the form are reserved for procedure-names, i.e., the names of 
sentences or sections. It is convenient to speak of this field as the name margin of the 
"Text" (see below) and to think of the procedure-names as "sticking out" into this 
margin. 

The rules for procedure-names are as follows : 

1. The procedure header, * procedure, is a special name that must appear on a 
separate line preceding each nrocedural portion of a source program to distin- 
guish it from data description or environment description. 

2. Procedure-names, like data-names, may contain up to thirty characters. Unlike 
data-names, however, they must be followed by a period and a blank. 

3. Procedure-names are written left-justified in the name margin and, if longer 
than six characters, extend into the "Text" area. 



Text 

(Col. 13-72) 



The procedure statements of the program are written in the "Text" area of the 
programming form. A number of examples in this chapter, as well as the sample 
program in Appendix 1 , illustrate the manner in which the procedure is stated. The 
clauses, sentences and sections of procedure are written in free form, subject to the 
following rules : 

1. A named sentence follows its name. That is, it begins to the right of the name 
margin, on the same line as its name. 

2. An unnamed sentence must begin on a separate line and to the right of the 
name margin. 

3. Succeeding lines of a sentence must begin to the right of the name margin. (If 
desired, they may be indented to facilitate reading the text.) 

4. When a section of procedure is begun, only the begin section command may 
appear on the same line as the name of the section. 

5. To end a section, the command "end section.name" is written as a sentence, 
i.e., on a separate line. 



Identification 
(Col. 73-80) 



Columns 73-80 can be used to identify the program. The information entered here 
will be the same for all lines on the page. The use of this area of the form is optional. 
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Presentation of 
Commands and Examples 



In the following description of the specific elements of the Commercial Translator 
procedure vocabulary, each command is represented in its "general form." In each 
case the general form is enclosed in a rectangular frame to distinguish it from text 
and examples. The verbs and other words which are a fixed part of the language 
appear in the general forms in boldface capital letters. The words and phrases 
representing names, clauses and sentences which will be written by the programmer 
are shown in lower-case italics. For reference purposes, the same general forms 
are presented in Appendix 2 in a more concise manner, without any discussion. For 
those commands that may contain a variable number of operands, a construction 
such as, "data.name.l, data.name.2, . . . data.name.n" is used to indicate that as 
many as "n" operands may be specified by the programmer. It is important to note 
that, except for imbedded periods within italicized words, any punctuation shown 
in the general form of a command is a fixed and necessary part of the command. 

In contrast to the general forms, examples of the various commands are written 
completely in capital letters and are not enclosed in frames. 



Program Commands 



Each of the Commercial Translator program commands causes some event or series 
of events to take place at object time, that is, the time at which the object program is 
run. The program commands are discussed, in turn, in the following pages accord- 
ing to the classification shown on the first page of this chapter. 



Input/Output Commands 



Within the category of program commands it is helpful to consider the input/output 
commands as a subgroup. The control of data flow through the data processing 
system is accomplished by means of an input/output control system. This system is 
called into play when the programmer uses one of the input/output commands in a 
statement of the procedure to be executed. The four verbs associated with these 
commands are open, get, file, and close. 

Using the input/output commands, the programmer initiates the movement of 
data into buffers or internal storage, the checking of the validity of the file itself, 
the checking of the validity of the input or output operation, the storage of data in 
internal storage to insure its availability when required, and finally, the making 
available or filing away of data according to the needs of the program. Thus the 
input/output control system provides data flow control and, where feasible, a "look 
ahead" at the data flow. 

The input/output control system in the Commercial Translator is a record proc- 
essing system. That is, the unit of data which is made available by the system and on 
which attention is focused during each processing cycle is the record. Should the 
needs of the program require that more than one record from a file be made available 
for processing at one time, it will be necessary for the programmer to provide work- 
ing storage into which he will move the additional records as required. 

The input/output control system provided in the initial version of the Commercial 
Translator is intended for the handling of tape and card files. The detection of errors 
is an implicit part of the tape and card handling system; error correction, where 
feasible, is handled automatically. More specific information on the use of the data 
flow control vocabulary is presented in the following paragraphs. 
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The OPEN 
Command 



The open command initiates the handling of one or more files. It mav take either 
of two general forms: 



The GET 

Command 



OPEN file.name.l, file.name.2, . . . file.name.n 
OPEN ALL FILES 



The first form of the command causes only the named file(s) to be opened. When 
the second form is used, all files specified in the environment description are opened. 
A given file must be opened, of course, before it can be addressed by a get or file 
command. 

If the file being opened is an input file, the following series of events occurs : 

1 . The label record, if any, is read into storage and checked for validity according 
to the standard label-handling conventions. 

2. Subsequent records are brought into the portion of storage governed by the 
input/output control system, filling the area which has been allocated to the file. 

3. Checking is performed, and a record count is initiated. 

In the case of an output file the following events occur: 

1. If specified by the programmer, a label record is created and written. 

2. Preparation is made to file data records in the output file as they become avail- 
able in processing. 

3= Checking is performed, and a record count is initiated. 

Some typical open commands are: 

OPEN INVENTORY.FILE. 

OPEN ALL FILES. 

OPEN STATISTICS, CUSTOMER.FILE, INVOICE.FILE. 

The get command is used to fetch records from an input storage area which is filled 
automatically from a file stored on tape or cards. The programmer need be con- 
cerned only with the use of single records since all auxiliary input operations such as 

unblocking 
tape alternation 
tape identification 
error checking 
reading ahead 

are automatically provided in the object program by the processor, based on infor- 
mation in the environment description. 

The get command may take either of two general forms: 



GET RECORD FROM file.name 
GET record.name 



The first form of the command assumes that the specified input file contains more 
than one type of data record. The record obtained may be of any type, and the 
programmer must arrange to identify the type. The second form implies an input 
file containing only one type of data record; the record is obtained from the file 
associated with "record.name" in the environment description. 
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Either form of the get causes the next record to be made available so that the 
entire record or any of its parts may be used in processing. Note that the previous 
record of the file is no longer addressable after the execution of a get command. 

To provide for the execution of an alternate command conditional upon end of 
file, the optional phrase, 



AT END any imperative clause 



may be appended to either form of the get. A command thus specified is performed 
after the last record of a file has been made available for processing and a subsequent 
get command has been encountered. The programmer should always use the at end 
option if the possibility exists of reaching end of file upon execution of the get. 
When the get command is executed at object time, the foUowing events take 
place : 

1. The next record of the file is made available for processing. 

2. If end of tape is reached, the end-of-tape label is read, and checks are made. 
The input tape is rewound, and provision is made for an alternate tape unit to 
be substituted. 

3. If end of file is reached, any alternate command specified in the at end phrase 
is performed. 

Some examples of the use of get are: 

GET RECORD FROM INVOICE.FILE. 

GET MASTER, AT END GO TO END.OF.MASTERS. 

The FILE The file command is used to place records on tape (for subsequent on-line or off- 

Command line processing), on cards, or on the printer. The programmer is concerned only with 

the placing of the unit record. Other considerations, such as 

blocking 
tape alternation 
file identification 
error checking 
setting checkpoints 

are provided automatically by the data flow control system based upon information 
supplied through the environment description. There are two forms of the file 
command: 



FILE record.name 

FILE record.name IN file. name 



In the first form the record is filed in the output file with which it has been asso- 
ciated through the environment description. In the second form the named record 
is filed from storage to the output file even though that record may not have been 
hitherto associated with that file. Creating new records in working storage and then 
merging them into a master file is an instance of the latter situation. 

When the file command is executed at object time, the following events take 
place : 

1. The named record is added to the list of those awaiting write-out. When the 
proper number of records has been accumulated, writing occurs. 
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2. When the physical end of a reel is sensed, the end-of-reel label is prepared and 
written, arrangements are made for alternation of tape units, and the tape is 
rewound. 

3. A count of the number of records written is maintained. 

It should be noted that a record that has been filed is still available for further 
processing. It is entirely possible, for example, to file a record in each of several 
files by means of a succession of file commands. 

Some examples of the file command are: 

FILE MASTER. 

FILE PAY.RECORD. 

FILE DETAIL IN ERROR.FILE. 



The CLOSE 

Command 



The close command terminates the use of one or more data files. It may take either 
of two general forms: 



CLOSE file.name.l, file .name .2 , . . . file.name.n 
CLOSE ALL FILES 



Data Transmission 
Commands 



In its first form the close command causes only the named file(s) to be closed. 
With the second form, all files defined in the environment description are closed. 

In the case of an input file the close command causes appropriate "housekeep- 
ing" operations such as: 

1. The record count is compared with the count in the end-of-file label if label 
records are present and if end of file has been reached. If the count does not 
agree, notification is given through external display. If the tape is not at end of 
file the record count is ignored. 

2. If the file is on tape, a rewind is initiated. 

3. The storage area allocated to the file is released for the use of other files. 

If the addressed file is an output file, operations such as the following occur: 

1. Any remaining information belonging to that file is written. 

2. If specified by the programmer, an end-of-file label containing the record count 
is written. 

3. The tape is rewound (if the file is on tape). 

4. The storage area is released for the use of other files. 

Each file which has been opened must ultimately be closed. 

Examples of the close command are : 

CLOSE INVENTORY.FILE, STATISTICS. 
CLOSE ALL FILES. 

The transmission of data from one area of storage to another is implicit in the 
functioning of a number of the Commercial Translator verbs. For example, the 
set verb requires the transmission of result data after the computation has been 
performed. Except for one verb, however, such transmission is incidental to the 
main purpose. It is the move verb which has as its primary function the transmis- 
sion, or movement, of data from one area of storage to one or more other areas. 
move and its alternate form, move corresponding, are used in writing the two 
uSiS transmission commanus, whicu are described in tue iOnOwing paragraphs. 
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The MOVE The move command calls for the movement of data from one area of storage to 

Command one or more other areas. Concurrent editing will occur automatically in certain cases 

depending on the format of the data as defined in the data description. The general 

form of the move command is: 



MOVE data.name.l TO data.name.2, data. name. 3, . . . data.name.n 



The data specified by "data.name.l" is moved to the area of storage designated 
by "data.name.2" and to any other area(s) mentioned in the command (data.name.3, 
. . . data.name.n). As used in this command "data.name" may represent data at any 
level defined in the data description (see Chapter 4). 

The following rules must be observed in writing move commands: 

1. Information from numeric fields may be moved to other numeric fields, to alpha- 
meric fields, and to report fields. 

2. Information from alphabetic or alphameric fields may be moved only to other 
alphabetic or alphameric fields. 

Some examples of the move command are : 

MOVE CURRENT.DATE TO CHECK.DATE. 

MOVE ZEROS TO MONTH.TOTAL, YEAR.TOTAL, CUMUL. TOTAL. 

Editing Feature 

Editing of the data in the sending area to conform to the format of the receiving 
area is a feature of the move command. Such editing occurs automatically if an 
explicit format definition, i.e., a field pictorial, is given in the data description for 
both the "from" and the "to" areas. (The field pictorial is a convenient method of 
describing formats and is discussed in detail in the data description portion of the 
manual; see page 79. ) 

The following conventions are observed in the editing feature of the move 
command: 

Numeric Information 

The data from the sending area is aligned with respect to the decimal point 
(assumed or actual) in the receiving area. Such alignment may involve the 
dropping of leading digits or low-order digits (or both if the sending field is 
larger than the receiving one). If the "from" area is smaller than the "to" 
area, the excess positions of the receiving area will be replaced by zeros. 

Alphameric Information 

If the sending area is larger than the receiving area, the data being moved will 
be left-justified and truncated; i.e., low-order characters will be dropped as may 
be necessary to make the data fit into the receiving area. If the sending area is 
the smaller, the data will be left-justified in its new location. The low-order 
positions of the receiving area, i.e., the excess positions, will be filled with 
blanks. 

A few examples are included below to clarify the editing feature. Regarding the 
pictorials shown in each case, for the purposes of these examples it is sufficient to 
know that the digit 9 represents any digit, the character A any non-numeric charac- 
ter, the character X any character, and that V shows the position of the assumed 
decimal point. 
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Sending Area 


Receiving Area 




Data 


Data 




Data 


Data 


Pictorial 


before MOVE 


after MOVE 


Pictorial 


before MOVE 


after MOVE 


99V99 


1234 


1234 


99V99 


8765 


1234 


99V99 


1234 


1234 


99V9 


876 


123 


9V9 


12 


12 


99V99 


8765 


0120 


AAAAA 


JONES 


JONES 


AAAAA 


VWXYZ 


JONES 


99999 


01234 


01234 


999V9 


7777 


2340 


AAA 


RUN 


RUN 


AAAXX 


JOB #2 


RUN 


AAAAA 


BLACK 


BLACK 


AAA 


RED 


BLA 



Note that in each case the data in the sending area remains unaltered after the 
move has been executed. Note also, in the sixth example, that the information in 
the two excess positions of the receiving area is replaced by blanks. 



The MOVE 

CORRESPONDING 

Command 



The move corresponding command permits the programmer to move groups of 
data from one area of storage to one or more other areas. The general form of the 
command is: 



MOVE CORRESPONDING data.name.l TO data. name. 2, data.name.3, 
. . . data.name.n 



This command can be thought of as a series of move commands, each of which 
is governed by the rules for move. It is assumed, however, that each "data.name" 
represents an area of storage which is subdivided into smaller areas such as fields. 
The effect of move corresponding is to move each field for which a corresponding 
field (i.e., a field having the same name) exists in the receiving area(s). The order of 
the corresponding fields need not be the same in the sending and the receiving 
areas. For example, the movement of data illustrated in the following diagram can 
be accomplished using move corresponding: 



'From' 
area 



"To" 
area 



Non-corresponding fields in the sending area are not moved. Non-corresponding 
fields in the receiving area remain unaltered. 

Editing Feature 

Automatic editing of data to conform to the format of the receiving areas is done 
in essentially the same manner as in the move command. Such editing, however, 
operates on subdivisions, or fields, of the data specified in the command. Accord- 
ingly, in order for editing to occur, the corresponding fields or smaller units must 
have explicit format definitions in the data description. 
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Arithmetic 
Commands 



The SET 

Command 



Two of the verbs in the Commercial Translator vocabulary are used for arithmetic. 
They are set and add. These two verbs form the basis for the three types of 
arithmetic commands, as follows: 

The set command permits the programmer to specify a computation or a sequence 
of computations. It can be used for all arithmetic. The general form of this com- 
mand is : 



SET variable. 1, variable. 2, 



variables = arithmetic expression 



The equal sign in the set command is used in the sense of replacement. It means, 
"replace the value of the variable(s) on the left side of the equal sign with the value 
of the expression on the right." If required, the result of a computation will be 
edited automatically according to the format of a receiving field as specified in the 
data description. For example, if a result represents an amount of money, editing 
appropriate to the defined format of the money field will be performed. 

Ordinarily the result of the set operation will be rounded to the number of places 
indicated by the format description of the result field or fields. If the dropping of 
digits (instead of rounding) is desired, the arithmetic expression is followed by 



TRUNCATED 



In the process of storing the final result of a set command it is possible for a loss 
of significant high-order digits to occur. For example, if a result field has been 
defined as having three places to the left of the decimal point and a result such as 
1001 is developed, the high-order "1" will be lost. This situation is known as 
"overflow." If the set command specifies just one result field (i.e., if it has only 
one variable-name to the left of the equal sign), the programmer may anticipate 
and provide for an overflow by appending 



, ON OVERFLOW any imperative clause 



at the end of the set command. In the event of an overflow, the object program 
will execute the command thus specified instead of storing the erroneous result. 

Some examples of the set command are: 

SET GROSS.PAY = BASE.RATE * 40. 

SET NET.PAY = GROSS.PAY - (FICA + STATE.TAX + 
DEDUCTIONS). 

SET A= B * (C + D), ON OVERFLOW GO TO ERROR. 

SET REORDER = ORDER. AMT * TR (STOCK.LEVEL LT 
ORDER.POINT). 

SET APPROX = 2 * SQUARE.ROOT ((X)) TRUNCATED. 

SET A, B, C =D. 
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The second of these examples shows the way in which subexpressions may be 
contained in parentheses when required. Likewise, the examples taken together 
illustrate the use of each element which may appear in an arithmetic expression, 
viz., arithmetic operators, names of variables and constants, literals, truth functions, 
and function-names. Each of these elements is considered individually below even 
though it may be discussed in greater detail elsewhere in the manual. (The formal 
rules governing the formation of arithmetic expressions are given in Appendix 2.) 

Arithmetic Operators 

The following arithmetic operators are used to join other elements to form mean- 
ingful arithmetic expressions : 

Operator Written as 

Addition + 

Subtraction — 

Multiplication * 

Division / 

Exponentiation * * 

These operators are sometimes referred to as "binary" operators because each 
of them relates two quantities. There are three additional arithmetic operators 
known as "unary" operators. They are: 

Operator Written as 

Negation — 

Absolute value ABS 

Truth value TR 

These operators affect only the quantity or expression which follows, hence the 
term unary. If the operand of a unary operator is an expression it must be enclosed 
in parentheses, as in these examples: 

. . . +ABS(A + B) 

...*(- (ON.HAND + ON.ORDER) ) 

. . . TR (A IS LESS THAN B) 

Variables and Constants 

Data-names which represent numeric variables or constants may appear anywhere 
in arithmetic expressions. Those which represent alphameric variables and con- 
stants, however, may appear only within truth functions. 

Literals 

Literals may be used as needed in arithmetic expressions. Literals used in the above 
examples of the set command are 40 in the first example and 2 in the fifth. 

Truth Functions 

A conditional expression enclosed in parentheses preceded by the truth operator 
TR is known as a truth function. A truth function always has one of two values, 
1 or 0, depending on whether the conditional expression is true or false. Accord- 
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ingly, a truth function can be manipulated arithmetically in the same manner as 
any other quantity. 

In the fourth of the preceding set command examples, tr (stock.level lt 
order.point) is a truth function. When the set command is executed, the relation 
between stock.level and order.point is evaluated. If the relation is true, that is, 
if stock.level is less than order.point, then the truth function takes the value 1. 
If the relation is false, it becomes 0. The result of this set command, then, is to 
cause the field reorder to contain the order amount if stock level is below order 
point, or zero if the stock level is at or above order point. 

Function-Names 

The names of functions are used in arithmetic expressions in much the same way 
as data-names or literals. That is, a function-name is treated as a quantity, as in 
the fifth of the preceding examples of the set command, where the square root of X 
is multiplied by 2 and truncated to obtain the result. There are some differences, 
however, between data-names and function-names. Data-names represent values 
which, at object time, are immediately available for arithmetic operations. Func- 
tion-names, on the other hand, imply an evaluation process at object time. The 
evaluation is carried out by procedural statements identified by a begin section 
command (see page 56). These procedure statements deliver a value to be used in 
computing the value of the arithmetic expression. 



SET Used with The set command has a second function that is not strictly arithmetic. It provides 

Condition Names a convenient way of changing the status of a conditional variable, i.e., a variable 

which has one or more conditions associated with it. When set is used for this 

purpose it takes the general form: 



SET condition. name 



As a result of this command, the variable with which "condition.name" is asso- 
ciated (in the data description) is assigned the status, or value, of the specified 
condition. 

Using the example mentioned in Chapter 2, if the current value of the variable 
marital.status is single and the programmer wishes to change it to married, 
he simply writes : 

SET MARRIED. 

This is the equivalent of writing: 

SET MARITAL.STATUS = 'M\ 

It is important to recognize the distinction between testing and setting the value 
of a conditional variable. Testing the value provides a basis for a decision but does 
not change the value; the testing is accomplished by using a conditional clause, 
if . . . then. Setting a value of a conditional variable, on the other hand, causes the 
current value to be replaced by another of the possible values and is effected by 
means of the set command. 
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The ADD 

Command 



The add command provides a way to add a given quantity to each of one or more 
variable quantities. The general form is: 



ADD data.name TO variable. 1, variable. 2, 



variable.n 



The ADD 
CORRESPONDING 

Command 



The effect of the add command is to increment the one or more named variables 
by the quantity represented by "data.name." In this context, "data.name" may be a 
literal or the name of a variable constant or f"*""*+'''»« 

The optional phrases truncated and on overflow described above in conjunc- 
tion with the set command are equally applicable to the add command. As in the 
case of set, the on overflow option is permitted only if the command specifies 
a single result field. 

Some examples of the use of add are: 

ADD GROSS.PAY TO YR.TO.DATE.GROSS. 

ADD 1 TO COUNTER, ON OVERFLOW GO TO BEGIN, 

ADD ADJUST.FACTOR TO RATE TRUNCATED. 

This command permits the programmer to specify a series of additions. Its general 
form is: 



ADD CORRESPONDING data. name. 1 TO data.name. 2, data.name. 3, 
. . . data.name. n 



Each "data.name" in an add corresponding command must represent an area 
of storage which is composed of smaller units or fields. The effect of the command 
is to cause each field in "data.name. 1" to be added to its corresponding field (i.e., a 

field With the Same Uam**^ i n tVi<» "tr»" arpo/cl MV-»n = <-/-»t~r<»cr\r\rirlirirr -fiol/^o in 

"data.name. 1" and in the "to" areas are not affected by the command. 

To illustrate, suppose that the programmer wishes to accumulate department 
totals and grand totals from certain fields in each detail record of a payroll. The 
detail-record fields involved might be gross.pay, fica, fed.tax, state. tax and 
deductions. Having defined dept. totals and grand.totals as records containing 
corresponding fields, the programmer could write: 

ADD CORRESPONDING DETAIL.RECORD TO DEPT.TOTALS, 
GRAND.TOTALS. 

This one command would cause all of the desired totals to be accumulated; it 
would have the same effect as writing: 

ADD DETAIL.RECORD GROSS.PAY TO DEPT.TOTALS 

GROSS.PAY, GRAND.TOTALS GROSS.PAY. 
ADD DETAIL.RECORD FICA TO DEPT.TOTALS FICA, 

GRAND.TOTALS FICA. 
ADD DETAIL.RECORD FED.TAX TO DEPT.TOTALS FED.TAX, 

GRAND.TOTALS FED.TAX. 
ADD DETAIL.RECORD STATE.TAX TO DEPT.TOTALS 

STATE.TAX, GRAND.TOTALS STATE.TAX. 
ADD DETAIL.RECORD DEDUCTIONS TO DEPT.TOTALS 

DEDUCTIONS, GRAND.TOTALS DEDUCTIONS. 
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Control 
Commands 



The GO TO 

Command 



The control commands enable the programmer to state the logical flow of a program. 
During the execution of the object program the procedure is normally executed in 
the order in which it appears in the source program. The control commands are 
used primarily to specify a departure from this sequence in order to execute some 
other portion of the program. The verbs that form the basis of the Commercial 
Translator control commands are go to, do, and stop. 

The go to command is used to specify transfer-type operations. It has three forms: 

Unconditional 

The unconditional go to is written: 



GO TO procedure. name 



It provides a transfer of control, or branching, to the item of procedure named 
in the command. The "procedure.name" may be the name of either a sentence or 
a section in the procedural part of the source program. 

Some examples are: 

GO TO MAIN.ROUTINE. 
GO TO CALC.ORDER.POINT. 

Conditional 

The conditional go to command is essentially a multiple branch or switching point; 
from this point, control may pass to one of several places in the program. As the 
name implies, the transfer of control depends on the truth or falsity of one or more 
conditional expressions. The general form of the command is: 



GO TO procedure. name. 1 WHEN conditional expression 1, 
procedure. name. 2 WHEN conditional expression 2, 
procedure. name. n WHEN conditional expression n 



When the conditional go to is executed at object time, each conditional expres- 
sion is evaluated in turn until one is found to be true. Thereupon, control is trans- 
ferred to the "procedure.name" associated with that conditional expression. Any 
remaining conditional expressions are left unevaluated. If none of the conditional 
expressions in the command is found to be true, control passes to the next clause 
or sentence in sequence. 

The following is a typical use of the conditional go to: 

GO TO ERROR.RTN WHEN DETAIL IS LESS THAN MASTER, 
PROCESSING WHEN DETAIL IS EQUAL TO MASTER, 
NO.ACTIVITY WHEN DETAIL IS GREATER THAN MASTER. 

Assigned 

The assigned go to command also serves as a multiple branch point in a program. 
In this case, however, the transfer of control depends upon the prior setting of an 
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index rather than on the truth or falsity of conditional expressions. The setting 
of the index may have occurred in one of two ways: 

1. Through bringing the index into storage as a constant or file variable. 

2. As a result of computation involving the index. 

The general form of the command is: 



GO TO ( procedure. 1, procedure.2, . . . procedure.n ) ON index.name 



A transfer of control will be made according to the value of the index at the 
time the go to is executed. If the value of the index is 1, control will pass to the 
first sentence or section of procedure named in the command; if 2, the second 
item named; and so on. 

The functioning of the assigned go to command assumes that the value of the 
index will always be an integer in the range 1 to n. If the index has any other 
value, no transfer will occur; instead, control will pass to the next clause or sentence 
in sequence. 

To illustrate, suppose that in a payroll job several different methods are used 
to compute gross pay depending on the employee's classification. The programmer 
might use an assigned go to command to effect a transfer to the appropriate rou- 
tine, as follows : 

GO TO (PIECE.WORK, INCENTIVE, HOURLY.RATE, SALARY) ON 
PAY.TYPE. 

The index pay. type in this case would be a field in each employee record which 
would contain a 1, 2, 3, or 4 depending on the employee's classification. 

Note that the parentheses shown in both the general form and the example are 
a fixed part of the command and must always be included. 

The DO The do command provides a means of departing from the normal sequence of 

Command program steps in order to execute some procedure, i.e., some other portion of 

program, and then return to the original sequence. In other words, the do is used 
to execute subroutines which, in the Commercial Translator system, are either 
named sentences or sections. 

The do command may take one of several forms. In the simplest form of the 
command the procedure is executed once each time the do is encountered. Expanded 
forms of the command permit repetitive execution, or "looping," of the subroutine 
and control of subscripts. Data substitution, which is an optional feature, is also 
provided. 

The simpler forms of the do command are: 



DO procedure .name 

DO procedure. name EXACTLY n TIMES 



where "procedure.name" represents the name of a sentence or section. (If a pro- 
cedure consists of more than one sentence, it must be defined as a section in order 
to be named. The processor commands begin section and end are used to define 
sections.) 

49 



Any procedure, i.e., any sentence or section, that is referred to by a do command 
must be what is known technically as a "closed" or "linked" subroutine. That is, 
it must be entered only through the use of a do command, and not by any other 
means such as transfer of control to a sentence within the procedure or through 
the normal passage of control to the first sentence of the procedure. It should be 
noted, however, that this rule permits the addressing of a procedure by more than 
one do command. 

When the do command takes the first of the two forms shown above, the "pro- 
cedure.name" subroutine is executed only once and control passes to the sentence 
or clause following the do. 

For example, the programmer might write: 

DO CALC.ORDER.POINT. 

IF ORDER.POINT IS LESS THAN 2.5 * MONTHLY.USAGE THEN 
GO TO . . . 

The do command in this example will cause the calc.order.point procedure 
(subroutine) to be executed once, whereupon control will pass to the if order. point 
is . . . sentence. 

With the second form of the command the "procedure. name" procedure is exe- 
cuted the specified number of times. The number of repetitions, n, may be stated 
as a literal or as a data-name, but in either case the value of n must be a positive 
integer. To illustrate this form of the do, suppose that in a payroll program a field 
called bond.accum is divided by another field, bond.denom, and the result trun- 
cated to an integer in order to determine the number of bonds purchasable. The 
result might be called no.of. bonds. Then the programmer could write: 

DO BOND.ORDER.RTN EXACTLY NO.OF.BONDS TIMES. 

This example assumes, of course, that the payroll program contains a procedure 
called bond.order.rtn which is used to prepare a file of bond orders. 

The DO Repetitive execution, or looping, of a procedure based on indexing is provided in 

Command the more powerful forms of the do command. To control a single index and/or 

with Indexing provide subscript control of the variables associated with the index, the do com- 

mand takes the form: 



DO procedure. name FOR index .name = p(q)r 



where "index.name" represents a field which has been defined in the data descrip- 
tion as an integer. The effect of this do command (in the object program) is to set 
the index to the initial value p and transfer control to the first sentence of the named 
procedure. After the last sentence of the procedure has been reached and executed, 
control is returned to the do command which increments the index by the quan- 
tity q and causes control to return to the "loop." This process is repeated until the 
value of the index equals r; at this point, control is no longer returned to the loop 
but instead passes to the sentence or clause which follows the do. To state this 
another way, the command, "do rtn for i = p(q)r" is the equivalent of: 
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SET i = 
START. DO rtn. 



IF i = r THEN GO TO NEXT. 
ADD q TO i. 
GO TO START. 



NEXT. 



Each of the loop control parameters p, q and r may be either of the following: 

1. A literal having an integer value. 

2. The name of a field defined as an integer. 

The following example shows a do command of this form : 

DO RATE.UPDATE.CALC FOR STATE = 1(1)50. 

In this example, each item in a rate table is being updated. The table contains 
fifty entries— a rate for each state. The procedure rate.update.calc might ap- 
pear as: 

RATE.UPDATE.CALC. SET RATE (STATE) = RATE (STATE) * 
ADJUST.FACTOR + FLAT.AMT. 

This procedure will be executed repeatedly, once for each value of the index 
state (from 1 through 50). The value of state (in the do command) at any given 
time specifies which table item is to be dealt with in the procedure. Thus, the vari- 
able rate is said to be subscripted by the index state. 

When it is desired to control two indices during the execution of a do, thus pro- 
viding a loop within a loop, the command takes the form: 



DO procedure. name FOR index.name.l = p.l{q.l)r.l, index .name .2 = p.2{q.2)r.2 



In this case, "index.name.l" and "index. name. 2" are initially set to p.l and p.2 
respectively. Each time the inner loop is executed, index.name.2 is incremented by 
q.2 until it equals r.2; thereupon, index.name.2 is reset to p.2 and index.name.l 
is set to p.l + q.l. Control is returned to the inner loop and the process is repeated. 
When index.name.l is equal to r.l, control passes to the clause or sentence which 
follows the do. 

A maximum of three indices may be controlled with the do command. Again, the 
rightmost index is the one which varies most rapidly. The following example illus- 
trates the do controlling three indices : 

DO COMPUTATION FOR HOURS = 1(1)12, MINUTES = 1(1)60, 
SECONDS = 1(1)60. 

In this case, the procedure computation is executed with the index seconds 
being incremented from 1 through 60 (in increments of 1), at which time minutes 
is increased by 1 and seconds again runs to 60. When the index minutes reaches 
60 the index hours is incremented by 1, and so on. After hours has reached 12, 
the loop is completed and control passes to the operation following the do. The 
subroutine will have been executed 60x60x12 times. 
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The DO 
Command 
with Data 
Substitution 



Frequently, a procedure which has been written for a particular purpose can be used 
at some other point in a program only if provision is made to substitute different 
items of data to be operated on by the procedure. Such substitution could be speci- 
fied by writing appropriate move commands in conjunction with the second do 
command. For example, if a procedure operates on three pieces of data called 
a, b, and c and produces two results, D and e, the programmer could use the pro- 
cedure with other items of data by writing: 

MOVE V TO A. 
MOVE W TO B. 
MOVE X TO C. 
DO PROCEDURE. 
MOVE D TO Y. 
MOVE E TO Z. 

Since this method is somewhat laborious, the Commercial Translator language 
provides a facility for writing procedures in a generalized form in order to accom- 
plish the same result. Procedures which are to be used with data substitution are 
always defined by the two processor commands "begin section using . . . giv- 
ing . . ." and "end" (see page 56). 

Data substitution can be specified in each of the several forms of the do command. 
When this feature is utilized, the general form of the simplest do becomes: 



DO procedure. name USING data.name.l, data.name.2, 
data.name.n GIVING result. name. 1, result. name. 2 
result, name, n 



Similarly, if data substitution is desired in the other forms of the do command, 
the "using . . . giving . . ." option is simply appended to the command. 

The "data. names" in the command specify the variable data, constants or literals 
which, at object time, are substituted for the data represented by the corresponding 
names (parameters) that appear in the "procedure.name" routine. Likewise, the 
"result.names" are the names which become associated with the outputs of the 
subroutine. 

The data substitution feature of the language being discussed here should not be 
confused with name substitution, which is another feature of Commercial Trans- 
lator. Name substitution is effected by the include command and occurs at proc- 
essing time; it involves the replacement of names in library procedures that are 
being incorporated in a program (see page 58). 

To illustrate data substitution using a more complete example, suppose that the 
following procedure has already been written into a program. This procedure is 
designed to determine a minimum value: 

MIN.ROUT. BEGIN SECTION USING A, B, C GIVING MIN. 

IF A IS LESS THAN B THEN MOVE A TO MIN OTHERWISE MOVE 

B TO MIN. 
IF C IS LESS THAN MIN THEN MOVE C TO MIN. 
END MIN.ROUT. 

In one portion of his program the programmer might have used this min.rout 
procedure to determine the lowest of three rates called r.rate, e.rate, and m.rate 
using the command: 
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alivj 3. C 



DO MIN.ROUT USING R.RATE, E.RATE, M.RATE GIVING MIN.RATE. 

The effect of this do command is equivalent to the following commands: 

MOVE R.RATE TO A. 
MOVE E.RATE TO B. 
MOVE M.RATE TO C. 
DO MIN.ROUT. 
MOVE MIN TO MIN.RATE. 

Now, in another part of the program, the programmer wishes to compare two ages 
onstant value to determine the lowest of the three values. The min.rout pro- 
cedure will serve the purpose in this situation as well. This time, however, the pro- 
grammer writes: 

DO MIN.ROUT USING INSURED.AGE, BENEFIC.AGE, 70 GIVING 
LOW.AGE. 

Again the appropriate data substitutions are made when the do command is ex- 
ecuted. As a result, the two values representing ages will be compared with the literal 
value 70, and the lowest of the three will become the value of low. age. 

The DO When a do command is compiled, the processor places appropriate instructions in 

Command the object program to effect transfer of control between the do and the associated 

with Named END procedure and to perform any indexing operations specified in the do. For correct 

functioning of the do, these control instructions must be executed each time an 
iteration of the associated procedure is executed. The control instructions are per- 
formed following the last program command specified in the procedure. Accordingly, 
a problem arises in the case of a multi-sentence procedure in which the last program 
command is executed only under certain conditions, i.e., when the logic of the pro- 
cedure requires a conditional exit prior to the last program command. The solution 
to the problem is to name the "end procedure.name" sentence which terminates the 
procedure and to use this name as an exit point. (Normally the end sentence is not 
named; this is the only exception to the rule.) This provides the necessary linkage 
with the control instructions. The following do command and its associated "rocedure 
illustrate this situation: 

DO REORDER.RTN FOR PART.NO = 1001(1)1499. 



REORDER.RTN. BEGIN SECTION. 

IF QTY.ON.HAND (PART.NO) IS GREATER THAN ORDER.POINT 

(PART.NO) THEN GO TO EXIT. 
SET REORDER.AMT(PART.NO) = ORDER. AMT (PART.NO) - 
QTY.ON.HAND(PART.NO). 
EXIT. END REORDER.RTN. 

In this example the logic of the procedure requires that the current iteration be 
terminated after the first sentence if the conditional clause is true. Assigning the 
name exit to the end sentence makes it possible to bypass the latter part of the pro- 
cedure and yet maintain the necessary linkage with the control instructions. 
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The STOP 
Command 



The stop command is used to specify a halt in the object program. Its general form 
is simply: 



STOP n 



Other Program 
Commands 



The LOAD 
Command 



where n is an integer. 

The number n will be displayed when the command is executed, i.e., when the 
machine halts. Restarting the machine causes execution of the object program to be 
resumed beginning with the next command in sequence. 

For a "dead-end" halt, an unconditional go to command placed immediately fol- 
lowing the stop can be used to effect a transfer back to the stop command. 

In addition to the commands described in the foregoing pages there are two program 
commands that do not fall into any of the four categories discussed. These "miscel- 
laneous" commands, which employ the verbs load and display, are described in 
the following paragraphs: 

Since an object program may exceed the capacity of internal storage, a facility is 
needed for keeping a part of the program in "standby status" (in external storage) 
and for calling it in to replace a portion of the program currently in internal storage. 
The load command, used in conjunction with the processor command overlap, 
provides this facility. The general form of the load command is: 



LOAD procedure. name 



The DISPLAY 
Command 



where "procedure. name" is the name of a portion of the program which, at object 
time, will be waiting in external storage. The load command causes this unit of pro- 
cedure to be brought into the area of storage shared by the procedures mentioned 
in the associated overlap command. The portion of the object program formerly 
occupying that area is replaced by the new portion but can be retrieved later by 
another load command. 

Any unit of procedure addressed by a load command must be named in an 
overlap command. 

The use of the load command is illustrated in the example given in the discussion 
of the overlap command (see page 56). 

At certain times during the running of the object program, the programmer may wish 
to examine particular values of data in internal storage, or may need to send mes- 
sages to the operator. The display command causes the object program to present 
such low-volume information on an appropriate output device or display medium. 
The general form of the display command is: 



DISPLAY 'any message' data.name 'any message' 



The display command displays all the information that follows the word display 
up to, but not including, a comma or period not enclosed in quotation marks. 
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The quotation marks in the display command have precisely the same meaning 
as in alphameric literals. The information within the quotation marks will be dis- 
played exactly as it appears in the command. Substitution of a value for its name 
may be specified by writing the name outside the pair(s) of quotation marks. That is, 
if the programmer wishes the current value of a data-name rather than the data-name 
itself to appear in a message, he arranges the text so that the data-name is not en- 
closed within a pair of quotation marks. 

To illustrate this point, suppose that the following command is written: 

DISPLAY 'VALUE OF WAGES LESS DEDUCTIONS IS NET.PAY'. 

The resulting display at object time will be: 

VALUE OF WAGES LESS DEDUCTIONS IS NET.PAY 

This is obviously not what the programmer intended. Had the command been 
written, 

DISPLAY 'VALUE OF WAGES LESS DEDUCTIONS IS' NET.PAY. 

the message at object time would be : 

VALUE OF WAGES LESS DEDUCTIONS IS $67.75 
assuming that the current value of NET.PAY was $67.75. 

The name of the variable outside the parentheses may be subscripted. It must rep- 
resent a defined field, however, and not an arithmetic combination of fields. 

The manual for each Commercial Translator processor will specify the standard 
uispiay device ior tue respective machine system. 



Processor Commands 



The OVERLAP 
Command 



The Commercial Translator processor commands are instructions to the processor; 
uxey cause me processor to taKe certain speciuc action. Some of the processor com- 
mands have an indirect effect on the object program. Others, such as note, have no 
effect whatsoever on the object program. In general, the processor commands do not 
generate instructions in the object program. 

An object program produced by the Commercial Translator system is organized as 
one loading of storage unless the programmer specifies otherwise by means of the 
overlap command. This command designates portions of the program that are to 
occupy (at different times) the same area in internal storage. The general form is: 



OVERLAP procedure. name. 1, procedure. name. 2, 
procedure, name. n 



As mentioned previously, overlap is used in conjunction with the program com- 
mand load, overlap instructs the processor to assign the same area of memory for 
the procedures mentioned in the command, load, on the other hand, causes one of 
the procedures to be called in at object time so that it can be executed. 

When the processor assigns storage space for the two or more procedures, it sets 
aside an area large enough to accommodate the longest. Thus when a procedure is 
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loaded over one which is longer, not all of the earlier procedure will be "erased." 
Accordingly, all overlapped procedures should have an unconditional go to as the 
last command. 

The loading of an overlapped procedure does not cause its execution. The pro- 
grammer must specify a transfer of control to the procedure by means of a go to 
or a do command. Also, care should be taken to insure that a load command does 
not appear within the procedure it obliterates. This would cause the destruction of 
the subsequent commands which effect transfer out of the procedure. 

When a source program includes one or more overlap commands, the object 
program will be organized as follows: 

1. The initial loading of storage will include all parts of the program not mentioned 
in any overlap, plus the first procedure named in each overlap command. 

2. Any procedures not included in the initial loading may be called in by a load 
command. 

3. Any procedure that has been obliterated by a load command may be retrieved 
(in its original form) by another load command. 

A simple example of the use of the overlap and load commands is as follows. 
The "housekeeping" portion of a program is to be executed and then overlapped by 
the main part of the program. Assuming that both procedures, i.e., both of these parts 
of the program, consist of more than one sentence, each must be treated as a section 
in order to apply names. The structure might be represented as follows: 

HOUSEKEEPING. BEGIN SECTION. 



, GO TO SUPERVISORS. 

END HOUSEKEEPING. 

MAIN.ROUTINE. BEGIN SECTION. 



END MAIN.ROUTINE. 
SUPERVISOR. 1. LOAD MAIN.ROUTINE, GO TO MAIN.ROUTINE. 

Elsewhere in the source program, probably included with the other processor 
commands, the programmer would write: 

OVERLAP HOUSEKEEPING, MAIN.ROUTINE. 

As indicated in the schematic program above, the program command, load 
main.routine, is placed outside the housekeeping routine, possibly in a short super- 
visory routine. 

The BEGIN SECTION The two processor commands, begin section and end, perform a simple but impor- 

and END Commands tant function. They are used to delimit sections of procedure and thus extend the 

range of a procedure-name. That is, they enable the programmer to give names to 
units of procedure that consist of more than one sentence. Unless begin section 
and end are used, a procedure-name applies only to the sentence which follows it. 
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This pair of commands is used as shown in the following general form: 



procedure. name. BEGIN SECTION. 
any sentence. 



any sentence. 

END procedure. name. 



Two of the program commands and one processor command take advantage of 
the facility provided by begin section and end. They are do, load and overlap. 
The usefulness of these commands would be seriously impaired if they could not 
operate on pieces of procedure larger than sentences. 

As indicated in the general form, the name of a section appears at the beginning 
and also at the end of the procedure. The second occurrence is required because 
sections of procedure may be "nested," i.e., one section may be contained within a 
larger one. For example, the situation illustrated below is permitted: 

NAME.l. BEGIN SECTION. 



NAME.2. BEGIN.SECTION. 



END NAME.2. 



y Section 2 



► Section 1 



END NAME.l. 



In this example, Section 2 is said to be nested within Section 1 . 

Normally the terminating sentence, "end procedure.name," is not itself named. 
There is one exception to this rule: The end sentence in a procedure associated with 
a do command may be named in order to provide a reference point at the end of the 
procedure (see page 53). 

As mentioned in the discussion of the do command, a section of procedure that is 
addressed by a do becomes a closed subroutine; it can be entered only through the 
use of one or more do commands. If a do command employs the optional data sub- 
stitution feature, the begin section command for the associated procedure becomes: 



BEGIN SECTION USING parameter. 1, parameter. 2, . . . 
parameter. n GIVING Junction. 1, function.2, . . . function.n 
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The "parameters" are the names of data which, at object time, will be replaced by 
the data specified in the using phrase of the do command. The "functions" are names 
representing results produced by the procedure; these results become the values of 
the result-names specified in the giving phrase of the do command. An example of 
the using . . . giving phrases is included in the discussion of the do command on 
page 52. 

Another point mentioned elsewhere should be noted in this context: The names 
of functions, i.e., the names of results produced by a section of procedure, may be 
used directly in an arithmetic expression instead of writing a do command. In this 
case, each function-name is followed by its parameters enclosed in double paren- 
theses. (See the discussion of functions in Chapter 2 and in this chapter on page 46.) 



The INCLUDE 

Command 



The include command causes the processor to extract a unit of procedure from the 
library and to insert it in the present program. The basic forms of the command are : 



INCLUDE library. procedure 
INCLUDE HERE library. procedure 



The "library.procedure" named in the command may be either a sentence or a 
section of procedure filed in the library under that name. The first form of include 
causes the procedure to be placed at the end of the present program. With include 

urnr +U ~ «~~„~^.,-„ i„ :„„„..*~,4 „.U ,,„- 4-U ~ „~.~.~,„~^ „~,~~„~„ TU« fi-„* f^~™ i „ 
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normally used to copy closed subroutines (i.e., procedures that are addressed by do 
commands) since such procedures must be set off from the main flow of the program. 
Procedures to be used "in line" are inserted by means of the second form. 

Name substitution is an optional feature of the include command which enables 
the programmer to rename the procedure itself and/or certain names within the 
procedure. The substitution is done by the processor at the time the procedure is 
included. To specify a new name for the procedure, an additional phrase is appended 
to the basic forms of the command: 



AS procedure .name 



If this phrase is used, all occurrences of the library procedure-name are replaced 
by the "procedure.name" indicated. Otherwise, of course, the procedure is refer- 
enced by means of its name in the library. 

Similarly, if names within the library procedure are to be replaced by new names, 
another phrase is appended to the command : 



. .WITH new. name. 1 FOR old.name.l, new. name. 2 FOR 
old.name.2, ... new. name. nY<SR old. name. n 



Again, all occurrences of the "old.names" are replaced by the specified "new. 
names." 
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The CALL 
Command 



The call command is used to specify alternate names, or synonyms, for previously 
defined names. The general form of the command is : 



The NOTE 

Command 



CALL {old.name.l) new .name .1 , (old.name.2) new. name. 2, . . . 
{old. name .n) new. name. n 



Synonyms are useful as abbreviations for often used names and as a means of 
communication between parts of a program, written by different programmers, that 
must refer to common areas of data. Data, work areas, and constants are capable of 
being named and thus may be renamed by means of this command. In the general 
form, the "old.names" are the names already defined, and the "new.names" are the 
alternate names being assigned. 

Some examples of the call command are: 

CALL (MASTERFILE) M. 

CALL (INSURANCE.PREM) INSPREM, (RETIREMENT.PREM) 

RETPREM. 
CALL (DEPARTMENT.TOTAL HOURS) DEPT.HRS. 

Synonyms must always be single names rather than compound names. A synonym 
may be applied to a compound name, however, as in the third example above. 

The note command enables the programmer to place explanatory information in 
the listing of the program. Its general form is : 



The ENTER 

Command 



NOTE any sentence. 



This command affects only the program listing, not the program itself. The sen- 
tence introduced by note will not produce instructions in the object program. 

Any combination of characters from the allowable character set may be placed 
after the verb note as explanatory information. Some examples are: 

NOTE START OF MERGE 1. 

NOTE UPDATE BEGINS HERE IF RATE HAS CHANGED. 

The note command is terminated by the first period that is followed by a blank. 

Although most source programs will be stated entirely in the Commercial Trans- 
lator language, there may be occasions when the programmer wishes to employ the 
symbolic "one-for-one" language of the particular machine system. The enter 
command instructs the processor to accept statements in another language. Its gen- 
eral form is : 



ENTER coding. language 



To revert to the Commercial Translator language, another enter command is 
required, specifically: 

ENTER COMMERCIAL TRANSLATOR. 

Further information regarding the particular symbolic languages will be provided 
in the publications dealing with the respective processors. 
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Relationship Between Program Commands 
and Processor Commands 



It will be obvious to the reader at this point that the program commands and the 
processor commands are essentially quite different. Accordingly, they cannot be 
intermixed in source program sentences. For example, it is meaningless to write 
sentences such as: 

IF A = B THEN GO TO C OTHERWISE OVERLAP SECTION. 1, 
SECTION.2. 

Processor commands, with the exception of begin section and end, should be 
written as unnamed sentences. This rule makes it impossible for a program command 
to transfer control to a processor command. (In a sense, begin section and end 
are not exceptions to the rule since their main purpose is to permit the programmer 
to apply a name to two or more sentences of procedure. ) This is not to say, however, 
that the two types of commands cannot appear in sequence in a source program. It 
is perfectly logical, for example, to use include here following a program command 
as long as the preceding sentence logically leads to the first sentence of the procedure 
being included. 
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Chapter 4: Data Description 



What a Data Description Is 

The preceding chapter has shown how to write instructions that direct the computer 
to perform various kinds of operations. Up to this point, the discussion has been 
limited to operations that act directly on the actual data of the problem being solved. 
It has been assumed that the various items of data had already been placed in the 
system for this purpose. 

In actual practice, however, the programmer must make the arrangements for 
placing the data into the system in a manner which permits it to be used efficiently. 
Although this is not difficult, it requires thoughtful planning. It assumes that the data 
is arranged according to a well defined plan, and it consists of furnishing the system 
with information about that plan. If the data is not suitably organized, the program- 
mer must work out an appropriate plan and arrange the data accordingly. The prin- 
ciples involved are not unlike those the programmer would follow if he were designing 
a set of business forms for handling the data manually. 

The need for doing this should quickly become apparent. Suppose, for example, 
that a clerk has jotted down on a scrap of paper the figures "46.30." These figures 
presumably represent a value that means something to him. But could anyone else 
tell what kind of a value this is? Is it, for example, a unit selling price? The number 
of hours worked by an employee? A discount? The percentage of water in a chemical 
product? Obviously, the number, standing alone, has very little practical significance. 

In normal business operations, of course, there are several means of identifying 
values of this kind. In some cases the number will actually be labeled. In many other 
cases its identity will be seen at once from the fact that it appears in a particular posi- 
tion on a particular form, or that it is written in a certain column in a certain ledger. 

When data is entered into a data processing system, it is rarely feasible to label 
each number. If "46.30" is a rate of pay, for example, the programmer would not 
write "$46.30 per 40-hour week." Neither would he write "46.30 lbs. per cu. ft." if 
it were a measure of weight. The value would be entered simply as a number, and 
the programmer would have to find some other way to show what the number repre- 
sented. The method of doing this is explained in this chapter. 

The Purpose of a It can be said, therefore, that a major purpose of writing a "data description" is 

Data Description to furnish the processing system with a means of identifying each item of data which 

has been named in the procedure statements. This description must include all items 

on which the system is to operate. 

Actually, the system needs more than a means of merely identifying the data. If 
the data is numeric, for instance, there must be a means of showing where the decimal 
point is located. If the system is to print out monetary values, it must have informa- 
tion on where to place the dollar sign, and whether or not to print leading zeros. 
Details of this sort are usually referred to as "editing." Some of them are handled 
automatically by the processor, so that the programmer need not concern himself 
with them. In other cases, the programmer can specify one of several methods for 
handling a particular situation; in such a case, the data description allows him to give 
the required instructions. 

Writing a data description is not difficult, once a few basic principles are under- 
stood, and these are explained in the following pages. The reader should realize, 
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moreover, that this method of describing data in a separate section of the program 
has a number of important advantages. 

In the first place, the typical program will deal repeatedly with data of the same 
kind. Use of a separate data description permits the programmer to describe each 
kind of data once, instead of having to describe each individual item as it occurs. 

A second consideration is that, once a given set of data has been described, the 
same description can be used again as part of a new program that works with the 
same data, or the same kinds of data. This would be a considerable advantage even 
if it were necessary to copy the data description into the new program by punching 
new cards. In practice, however, the data description can actually be stored in the 
library, on tape or in cards, so that it can be called for when needed. 

Finally, the Commercial Translator data description is so designed that a program 
developed for use on one data processing system can be run on a different kind of 
system (within limits) with relatively few changes in the data description. A basic 
reason why this is possible is that the data description is tailored to the logical struc- 
ture of the data files, which do not alter materially from machine to machine, while 
most of the details that relate to actual equipment are handled by the processors fur- 
nished for the various machine systems. The programmer is thus spared many of 
the problems that can arise when it is necessary to run a program on a system other 
than the one for which it was originally designed. 

A data description for a data processing system contains a number of elements 
which are already familiar to those who have worked with punched card equipment. 
As most readers will recognize at once, punched card operations require that data be 
arranged in the cards in accordance with a definite pattern. In essence, each item of 
data is identified by its physical position in the card. Thus, if the first six columns of 
a deck of payroll cards are reserved for employee numbers, the system will treat all 
values in those columns as employee numbers, unless special coding is used to 
indicate exceptions. But any such exceptions must be indicated by codes which are 
themselves identifiable by their positions in the card. In short, the key to identifying 
a value in a punched card is its position in the card. 

The same basic rule a nr *lies to electronic s v stems but the number of n ossible posi- 
tions is greatly increased. Moreover, data can be shifted from one position to another. 
Yet it is always the position of the data that identifies it, and it is one of the functions 
of a Commercial Translator processor to keep track of the position of each item. 

For this reason, a major part of a data description consists of the details necessary 
to determine the position of each item. Among other things, it is necessary to give 
the length of each kind of item (that is, the space it will require) and its relative posi- 
tion in the file. The processor will use this information to assign an initial location 
in storage for each kind of data. At the same time, it will note the name which the 
programmer has assigned to the item. By relating this name to the location, the 
program will be able to find the item when it is referred to by name. Furthermore, 
it will keep track of all changes in the position of the item; this saves the programmer 
from having to deal with internal addresses in the system and permits him to refer 
to data by name. 

It follows, of course, that the efficiency of the program will depend in part on the 
arrangement of the data. The data description provides for describing a data organ- 
ization already in existence. If the arrangement of the data does not take full advan- 
tage of the capacities of the system, the programmer may wish to reorganize the 
original input data before writing the data description. 
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Files, Records, Before proceeding with the details of the data description it is only necessary to 

and Fields define three terms as they are used in the Commercial Translator system: "file," 

"record," and "field." The exact implication of these terms varies from person to 
person and company to company. In this manual they are used to distinguish between 
kinds of data that can be operated on by different Commercial Translator instruc- 
tions. Thus, the verbs open and close can operate only on files, and a file must 
therefore be regarded as a body of data organized for use within the scope of those 
commands. Similarly, the verbs get and file can operate only on records, so that a 
record can be defined as a body of data which can be governed by those commands. 
Fields, on the other hand, are subordinate units of data and are not readily definable 
in terms of the commands that affect them. While these definitions may seem some- 
what arbitrary, it will be found that in practice they correlate with normal principles 
of data organization. 

Files 

A file is a body of data stored in some external medium which can be made acces- 
sible to the system by the use of the verb open. In this sense, an external medium is 
any medium which provides input to the system from without. Data in such a medium 
cannot be used by the system until it has been brought into it, which is the basic 
purpose of an open command. The usual external medium of electronic data proc- 
essing systems, of course, is magnetic tape. 

The concept of a file as "external" to the system carries certain implications which 
should be considered. These arise, not from the definition of a file, but rather from 
certain practical considerations. 

For example, a file is usually a relatively large body of data, although there is no 
implied relationship between the length of a file and the storage capacity of a tape. 
Thus, there may be more than one file on a tape, and, on the other hand, a file may 
extend over a number of tapes. 

A file is commonly understood to consist of a number of individual records, the 
records being generally similar to each other in size, content, and format. (Some- 
times a series of differing records may be grouped together in a file; in such a case, 
the programmer must make provisions for distinguishing among them.) The file 
itself may be unique, or it may closely resemble other files. Thus, a file of actuarial 
data might be the only one of its kind in a library, while a file of insurance policy 
data might differ from another chiefly because it covers a different area or a different 
period of time. In this sense, a file serves a function like that of a ledger, or a filing 
cabinet containing a series of similar papers. It is usually a rather large body of 
related information. Thus it is convenient in most cases to treat such large bodies of 
data as complete and separate units which can be identified externally by direct 
reference to the physical media in which they are stored. Such media may be con- 
trolled only by the open and close instructions, and this fact accounts for the defi- 
nition of a file used in the Commercial Translator system. 

Many files contain special records which are used primarily to identify the file and 
its contents. These records are called "labels." If labels are used, one is normally 
placed at the beginning of the file, and another is placed at the end. These labels 
correspond in many ways to the labels on file drawers, except that certain technical 
information is required because of the nature of an electronic system. Many of the 
details of labeling are handled automatically by the "input-output package" provided 
for each system. Most labeling procedures are prescribed in the environment descrip- 
tion for each machine system, and will be discussed, therefore, in the publication 
covering the Commercial Translator processor for each particular system. However, 

63 



the programmer has the option of prescribing certain details of a label by the use of 
the label type code, which is discussed later in this chapter. 

Records 

A record is a portion of a file which can be made accessible to the system by the 
verb get, assuming the file has previously been "opened." The size and position of 
a record in storage are determined by the specifications given in the data description. 
Its contents are referred to by their location in storage, whereas a file, as such, is 
never actually brought into storage. In other words, a record, unlike a file, is con- 
ceived as an "internal" body of data, even though it may be stored externally for long 
periods of time as part of a file. 

Usually, but not necessarily, the records within a file are similar to each other in 
content, size, and format. For example, there might be a file called payroll record 
— eastern region, which would contain hundreds, or thousands, of individual pay- 
roll records. Each individual record would normally contain data relating to a par- 
ticular employee, such as his name, employee number, job title or class, pay rate, 
dependency classification, deductions, and so on. The separate parts of a record might 
be quite dissimilar, but they would all relate to a single subject (in this case, an 
employee), and other records in the same file would carry similar information about 
other employees. Furthermore, each item would occupy the same relative position 
in one record that it does in another; it would also have the same format and be of 
the same size. This makes it possible to describe each kind of data instead of each 
individual item of data. 

A record may be obtained for use by the verb get, and, when processing has been 
completed, it may be placed in an output file by the verb file. 

Fields 

A field is a block of data which can be operated on as a unit by the arithmetic com- 
mands and by the commands that control the movement of data within the system 
(other than the verbs get and file). In many cases, a field will be a subordinate 
part of a record (such as a pay.rate field within a record called pay.record). 
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field, for example, and, in fact, several records, or parts of several different records, 
may be regrouped within storage to form a new block of data which can then be 
treated as a field. Fields must always be defined in the data description. 

In most cases, a field is considered to deal with only one element of data, at least 
for the purposes of the operation being performed. In a payroll record, for instance, 
such items of data as employee name, pay rate, employee number, and so on, would 
each be treated as a field. In practice, a field may be further subdivided. The classic 
example is the representation of a date. According to one view, the complete date, 
consisting of day, month, and year, is a single field, and the smaller components are 
regarded as "subfields." Another view holds that day, month, and year are each fields, 
and that the complete date is a group of fields. 

As far as the Commercial Translator language is concerned, however, distinctions 
between subfields, fields, and groups of fields are handled by assigning "level" num- 
bers to the various components. This is explained later in this chapter. It is felt that 
this method eliminates confusion that could result from trying to show relationships 
among the smaller units of data by the use of only three terms (i.e., field, subfield, 
and group of fields), and it allows, through the use of level numbers, a greater degree 
of flexibility in organizing the data. In general, it should be understood that a field is 
any element of data which can be operated upon by arithmetic and/or data trans- 
mission verbs. 
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Data Description Format 

The detailed information which must be supplied in order to describe the data fully 
can be entered into the system easily by the use of punched cards. A separate card is 
used for each kind of data item. The format of the card is reflected in the data de- 
scription form, which is illustrated in Figure 1 . 

The spaces on this form correspond exactly to the columns of the cards, so that 
the information written on each line of the form can be punched directly in a card 
without editing. Since the form provides a field for each of the various kinds of 
information required, it will serve in this chapter as a convenient check-off list by 
which to list and discuss each of the items required in the data description. 

A "division header" must be placed immediately before the first entry of each 
consecutive group of data description cards. The name *data, placed so that the 
asterisk is in Column 7, should be the only entry on the line (i.e., card), except for 
the serial number and identification entries in Columns 1-6 and 73-80. 

General As will be seen from the illustration, the form provides spaces for each column in the 

card. The spaces representing Columns 1 through 3 and 73 through 80 are shown 
only once, since the information they will contain is assumed to be repeated for each 
line of the form. The information to be written in Columns 4 through 72, however, 
will vary from card to card, and spaces corresponding to these columns are therefore 
provided on each line. 

The programmer should follow these space marks exactly, so that each item of 
information will be punched in the columns reserved for it. It will be noted that the 
data description format differs from the procedure description format in several ways. 
In particular, the former is more rigid; it does not allow "free form" description. 

The columnar format of the card is summarized in the following table: 





Number 






of 




Columns 


Columns 


Use 


1-6 


6 


Card Serial Number 


7-22 


16 


Name 


23-24 


2 


Level Indication 


25-30 


6 


Type 


31-35 


5 


Quantity 


36 


1 


Mode 


37 


1 


Justification 


38-71 


34 


Description 


72 


1 


Continuation Indication 


73-80 


8 


Identification 



Ctl. and Serial It is essential that each item of the data description be entered into the system in 

(Col. 1 -6) proper sequence, since the sequence controls the internal position of the data. The 

first six columns are reserved for a serial number, which is used to indicate the 
sequence of the cards. This number is normally numeric. Its first three digits are 
written in the box marked "ctl" (for "control"), which corresponds to Columns 1 
through 3. It is assumed that the first three digits will be common to all serial numbers 
written on the same page. Although these digits must be punched in each card, it is 
sufficient to write them once in the ctl box, instead of repeating them on each line. 

The remaining digits are written in the box labeled "serial," which corresponds to 
Columns 4 through 6. In normal practice, only Columns 4 and 5 are used initially, 
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and Column 6 is left blank. This makes it possible to insert correction cards later if 
necessary. The blank is the first character in the collating sequence and will therefore 
be placed in sequence before any other character in the same column. Thus, if the 
numbers 23 and 24 have been punched in Columns 4 and 5, each will be read as a 
three-digit number with a blank in the third position, and a correction card with the 
number 235 would be collated between them. 

When the cards are read into the data processing system, their serial numbers will 
be checked for correctness of sequence. In all ibm machines the numeric collating 
sequence is, first, the blank, then the numerals from to 9. Alphabetic characters, 
if any, will be checked for sequence in accordance with the collating sequence of the 
particular machine system. 

Data Name Columns 7 through 22 are reserved for any name which the programmer may have 

(Col. 7-22) assigned to the data described in the card. The rules for forming names (see page 15) 

state that a name may contain as many as 30 characters. The card format provides 
only 16 columns, however, so that any name having more than 16 characters must 
be carried over to the "Data Name" columns in a succeeding line. In order for the 
processor to recognize this situation, the programmer must place a character in the 
continuation indication column (Column 72). Any non-blank character will serve 
the purpose. The processor will then be able to combine the two parts of the name 
into a single name. The programmer need not worry about the point at which the 
break between lines occurs; the processor will close up any blanks occurring in the 
"Data Name" columns. This provision allows the programmer to indent the carry- 
over if he wishes. 

Names are usually written with an assumed left margin immediately to the left of 
Column 7. They may be indented from this assumed margin if the programmer 
wishes, but the processor will ignore any indentation. If no name is assigned, Columns 
7 through 22 should be left blank. 

Names may be assigned to any item of data, or to any group of data items stored 
consecutively within the system. Thus, names may be given not only to groups of 
items in the input files, but also to groups formed within storage as a result of opera- 
tions performed by the system. Any name so assigned may be used as an operand 
in a procedure statement. 

All data-names used in the program must be defined in the data description. In 
actual operation, the system will convert these names to actual machine addresses 
when the object program is assembled and will use those addresses as the actual 
means of locating the data. The purpose of writing the names in the data description 
is to furnish the processor with the information it needs to do this. 

Data-names must not overlap. Each field within a record can be given a name, 
and any group of consecutive fields can also be given a name. Thus, a single field 
may be operated on individually by reference to its name, or collectively as part of 
a group called by the group name. However, the same field may not be included as 
a part of each of two overlapping named groups of fields. 

For example, if three successive fields are named A, B, and C, the group name X 
might be assigned to the pair A and B. If this were done, the name Y could not be 
assigned to the pair B and C, since field B is already part of a named group of fields. 
If the programmer needs to be able to refer to fields B and C by a single name, how- 
ever, he can rename the entire group of three fields, using the redef type code de- 
scribed later in this chapter. This procedure would not delete the original names; 
the new names and the names originally assigned would all be available for use 
thereafter. 
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Level Level numbers are used to describe the way in which a body of data is organized. 

(Col. 23-24) Basically, level numbers are assigned to items of data to show their relationship to 

other items of data — or, in other words, to show the structure of a record. Any 
number from 1 to 99 can be used. All data description entries must be assigned 
level numbers. 

In general, each item is considered to be a subdivision of the last item preceding 
it which has a lower number. Figure 2 shows how a typical series of files, records, 
and fields might be organized, using the familiar method called outlining. The file 
structure is shown by the use of indentation, each item being considered a part of the 
last item above it which is indented to a lesser degree. 

The technique of indentation, in other words, is a visual way of showing level. It 
may be used in the "Data Name" columns, but it will have no effect on the processor 
itself. However, since it helps to identify the various levels visually, indentation may 
be useful in clarifying the file structure when the program is listed. 

For comparison, two additional columns have been provided at the right in 
Figure 2. These show the data classification of each item, together with hypothetical 
level numbers such as might be assigned to a file structure of this kind. It should be 
pointed out that entries for files and groups of files are not actually used in the data 
description. 

It is obvious from the outline that each item from employee number through 
location is a part of pay record, and that each item from fica through hospital- 
ization is a part of deductions, year to date. Had the principle of indentation 
not been used, the reader might still determine these relationships by examining the 
level numbers in the ri^ht hand column, following the rule that each item is part of 
the next item above with a lower number. The processor, of course, will ignore any 
indentation and will store the data in accordance with the level numbers. 

It is not necessary that level numbers be assigned in consecutive order, although 
it is done that way in Figure 2. The items at level 02, for example, might have been 
assigned level 04, or any other convenient number, as long as it was greater than 01. 
Similarly, the items at level 03 could have been given any other number as long as 
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useful to skip numbers when they are initially assigned, to allow for possible re- 
groupings or insertions at a later time. 

The reader will also note that each item at the record level and below represents 
a kind of data, not a specific item of information. Thus, although there will be only 
one file called eastern region sales force, within that file there will be many indi- 
vidual units called pay record, and each of these will contain information of the 
same general character and format, as specified by the names of the fields within it. 
The purpose of the data description is to give information about each of these kinds 
of data. The data description should be thought of as a "pattern" which the files 
will follow. 

It may be helpful to consider a second method of showing how data may be 
organized. Figure 3 shows how the same payroll file might be represented in the 
form of an organization chart. 

This chart demonstrates one important fact: Each item of data is, or may be, re- 
lated to other items above and below it. In other words, the data is organized "verti- 
cally" — no item is related directly to any other item at the same level, except through 
an item at a higher level. One result of this is that if a particular item is of the same 
kind as other items in the file, it may be identified by reference to the item above it 
in the organization structure. Thus, the name pay record does not single out any 
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Organization of Payroll Files 
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* Files and groups of files are not actually entered as such in a Commercial Translator data 
description. Also, none of the names is in Commercial Translator format. 

Figure 2. Typical File Structure (theoretical) 
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ORGANIZATION OF PAYROLL FILES 
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Figure 3. Typical File Organization 



one unique kind of item, but sales force pay record distinguishes one kind of item 
from any item designated production force pay record. Similarly, since in this 
illustration there are two sales force files, each can be identified by reference to the 
next higher level. Thus, a particular kind of item might be known as eastern region 
sales force pay record. 

The use of a higher name to identify a lower one is known as "name qualification," 
and a name so qualified is known as a "compound name." This is an important 
method of identifying individual items which do not have names unique in the pro- 
gram. It is true that in this illustration the qualifying names are those of files. How- 
ever, the principle is applicable internally, within files, whenever it is necessary to 
distinguish between fields having the same name. (See the discussion of compound 
names beginning on page 15.) 

Level numbers are not actually attached to the data in the sense that an employee 
number is part of a pay record. They are used to instruct the processor to perform 
certain technical functions which need not concern the programmer. Essentially, they 
are used before the actual data is read into the system, as a means of preparing the 
system to receive it. Once the data description has been written, the programmer 
need no longer concern himself with level numbers unless, owing to changes in the 
data or the program, a new data description should become necessary. 

Type Columns 25 through 30 are used, when necessary, to show that the data being de- 

(Col. 25-30) scribed is of a certain special type. If these columns are left blank, it will be assumed 

that the remainder of the particular entry describes a data field or group of fields. 

The type codes which may be used in these columns are the following: 

RECORD 

COND 

FUNCT 

PARAM 

REDEF 

COPY 

LABEL 

Each of these is discussed in the following pages. 
RECORD 

This type code shows that the data being described is a record and is therefore ac- 
cessible by get and file instructions. This is equivalent to identifying an item of 
data as an input/output record. Each record named in the data description must also 
be named in the environment description, as specified in the publication covering the 
processor for each particular system. 

COND 

The type code cond is used to show that the data referred to is one of the possible 
conditions which a conditional variable may assume. In the discussion of conditional 
expressions in Chapter 2, it was pointed out that a conditional variable is the name 
of a field which will contain, at different times, any of a number of different values, 
depending on conditions existing in the data. Each of the values that may be placed 
in the field is a "condition." 

In an example used in Chapter 2, the name marital. status was given as the 
name of a conditional variable. This name refers to a specific field reserved in storage 
into which values representing conditions will be entered. Typical conditions for this 
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field would be "single," "married," and "divorced." While these words could actually 
be placed in the marital.status field, it is more economical of space, and generally 
more efficient, to use codes. The initial letters m, s, and d were used as codes in this 
example. Thus, the field marital.status might contain any one of these letters at a 
given time. 

However, so that the programmer can refer to these codes by their names, he must 
specify in the data description which code corresponds to each name. This may be 
done in the following manner: 

Suppose that the field marital.status has been given the level number 06. The 
names of the conditions which may be entered into the field must then be assigned a 
lower level (i.e., a higher number) and entered in the data description immediately 
following the name of the field. This means that they will be treated as if they were 
each a subdivision of the field, in accordance with the rules for assigning level num- 
bers, although, in practice, only one condition will be considered at a time. A portion 
of the data description might then appear as follows: 
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The entries under "Description" will be explained later in this chapter, but, in 
summary, the "a" indicates that the field will contain one non-numeric character, 
while the initials s, m, and d are enclosed in quotation marks to show that they are 
the actual values to be used in the program. 

In this example, the fact that the names single, married, and divorced are the 
names of conditions is shown by the use of the type code cond. The relationship of 
these conditions to the field marital.status is shown by the fact that the condition- 
names have a higher level number and follow the name of the conditional variable 
immediately. 

It should always be remembered that the condition-name is the name of the value 
which can be placed in a field; it is not the name of the field itself. As was pointed out 
in Chapter 2, the condition-name married, in this case, would be equivalent to 
marital.status = 'm'; it follows that such expressions as set married or if married 
will be interpreted to mean set marital.status = 'm' and if marital.status = 'm' 
respectively. The condition-name, in other words, is a short way of writing an expres- 
sion that shows the value in the field. 

It is not always necessary to list condition-names in the data description in the 
manner shown above. If the programmer, when he writes the source program, limits 
himself to the full form of conditional expressions (such as if marital.status = 'm' 
then . . . ) , he need not assign names to the conditions. However, if he wishes to use 
the shorter and more convenient method of referring to conditions by name, he must 
write a data description entry for each. 
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FUNCT 

A function has been defined in Chapter 2 as a result obtained by following a proce- 
dure. In the Commercial Translator system, the term is used only in connection with 
procedures specified in the begin section command. Any data-name specified in the 
giving clause of the begin section command is a function in this sense, and it must 
be identified as such in the data description. The function-name is identified by the 
type code funct, and the function must be fully described in accordance with the 
provisions of this chapter. The parameters written in the using clause of the begin 
section command must be identified in the data description by the type code param, 
as explained immediately below. (See the discussion of functions in Chapter 2 and the 
begin section command in Chapter 3. ) 

PARAM 

The type code param is an abbreviation of the term "parameter." It is required, if 
appropriate, to show that the item of data being described is a parameter for use in a 
routine used to obtain a function. (See the discussion of functions in Chapter 2, the 
command begin section in Chapter 3, and the type code funct above.) 

Specifically, when the program contains a section introduced by a begin section 
command, each data-name listed in the using clause of that command is a parameter, 
and it must be described as such in the data description. 

REDEF 

The code redef is used whenever it is necessary to redefine an area or an item of data 
that has previously been defined in some other way. This is usually necessary when- 
ever a portion of the program "overlaps" another — i.e., when it calls for the use, on 
a "time-sharing" basis, of data or storage space which has previously been defined 
for some other purpose. It is also used in setting up tables in the system. 

For example, it may be necessary to call existing data by a new set of names, or to 
reorganize it by altering the groupings and/or the subordinate level numbers. Fre- 
quently it is necessary to wipe out data to make room for other data. In any such 
case, a new data description is required for the new items or the new names. How- 
ever, the name or names of the areas being redefined must first be listed, using the 
type code redef to show that the accompanying data description may also be used 
to refer to the same area. The redef entry must have the same level number as the 
entry being redefined. An illustration will be found later in this section, in the discus- 
sion of tables, on page 75. 

Use of the redef code does not erase data in storage, unless an attempt is made to 
place two or more different constants in the same area; however, it does superimpose 
a new format upon the data already present. If the programmer wishes to change an 
item in storage, such as a value in a table, he may do so by using a move instruction 
that specifies the new data and the position in storage where it is to be placed. 

Redefinition does not cancel the previous definition. It merely makes it possible 
to refer to the same area by different names and for different uses. Once an area has 
been defined, all names associated with the definition may be used at any time, re- 
gardless of subsequent redefinitions. 
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Tables 

A valuable function of the redef code is to make it possible to set up tables in storage 
and to define the methods of locating individual items in the tables. The following 
example shows a method of doing this : 

Suppose the programmer wishes to place in memory the table described in 
Chapter 2 (see page 29), which shows passenger transportation rates to each of 30 
different cities. Each line in this table lists a city, a one-way rate, a round trip rate, 
and an excursion rate. If it were printed in a book of rate schedules, it would probably 
contain four columns, headed "City," "One- Way," "Round Trip," and "Excursion." 
A portion of this table might have the following form: 



City 



One-Way 



Round Trip 



Excursion 



Los Angeles 
Miami 



153.42 
78.60 



285.16 
141.63 



212.87 
118.92 



To place such a table into a Commercial Translator program, the programmer 
must first analyze it to determine the maximum size of each kind of item. He may 
find, for example, that 14 character spaces will be required for the longest name in 
the "City" list, and that each of the rate listings can be accommodated if space for five 
digits is reserved for each rate value. 

The actual data may then be entered by copying all of the individual items in se- 
quence, reading across each line and allowing blank spaces (or zeros) as filler in 
those items that occupy less than the allowed space. Thus the initial data entry might 
read, in part: 



iDESCRIPTION 




**■'■ 



I I I I I I 



'I'll' 



"l c ^l g l a l I 



I I I I I t I 1 I I 



I I I I I I 



I I I I I I I I 



/^j^^r.fVig.Zi/.^y/, ,\ 



^7,y l *,g,/,y l /,*,.?,// l ;',?,*, / , , 



The entries at the 02 level, which could extend over as many lines as necessary to 
accommodate all of the data, specify a series of constants. These are enclosed in 
quotation marks in accordance with the rules for writing constants. Note that decimal 
points are not normally required in constants of this kind, since the location of the 
decimal point will be specified in a later entry. 

The result of this entry is twofold: Space is reserved in memory for the entire 
table, and the individual items are stored in a sequence which permits them to be 
located after the table has been more fully described. At this point, however, no 
means of identifying any single item of data has yet been established. This must be 
accomplished by superimposing the format and structure of the table on the data 
already placed in storage. It is done by redefining the format of the data, using a 
series of entries such as the following: 
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SERIAL 
4 6 


DATA NAME 

7 22 


23 24 


TYPE QUANTITY 
25 30 31 35 


s 

36 
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DESCRIPTION I 
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1 ! 
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In the first of these entries, the data previously defined as rate. table is redefined 
(by the type code redef) as a new body of data. In this case a name has not been 
given to the redefined data, but the programmer could assign one if he wished. It will 
be noted that the level of the new entry (01) is the same as that of the entry being 
redefined. 

The rate entry and the four data-names which follow it (city, one. way, 
round.trip, and excursion) are on lower levels (02 and 03); therefore, they will 
be understood to be subordinate elements of the entry at the 01 level, and the code 
redef will apply to them as well. 

The number 30 in the "Quantity" columns, as will be explained later in this chap- 
ter, shows that space is to be reserved for 30 entries at the 02 level. In other words, 
there will be 30 items called rate. It will be seen later that the programmer may 
single out any one of these items by appending a subscript to the name rate. This 
subscript may be a literal, a data-name, or a limited arithmetic expression. The value 
represented by the subscript must be a positive integer, since it will be used within 
the system to count individual items until the required one is reached. (See the dis- 
cussion of lists, tables, and subscripts in Chapter 2.) 

It has been noted that the name rate includes all of the four items immediately 
following it. Thus, each of the 30 rate entries will contain one called city, one 
called one.way, another called round.trip, and a fourth called excursion. Since 
30 separate rate entries were specified, the processor will lay out this entire sequence 
30 times. 

The characters in the "Description" columns show the length and type of data to 
be expected in each field. This is explained more fully later in this chapter, but the 
effect of the entries given in the example is as follows: The 14 a's following the name 
city will reserve space in storage for names of up to 14 characters in length. The 
symbols 999V99 will reserve space for five-digit numeric values, with an assumed 
decimal point between the third and fourth digits. 

Once the processor has this information, it can identify and use any single item of 
data in the table. It will know, for example, that the first 14 character spaces of each 
rate listing contain the name of a destination city, that the next five show the cor- 
responding one-way rate, and so on. In other words, it now has the means of locating 
any item by its position in storage, which, as has been noted already, is the way in 
which the system locates all items of data in storage. 

The programmer may then call for any individual item by its name, using a sub- 
script to specify which one of the 30 items having the same name is wanted. Thus, 
one.way (17) would obtain the one-way rate for the 17th city in the table. Usually, 
however, the subscript would be a variable, such as the name of a field containing a 
number. 
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Suppose, for instance, that the input record contains a field called destination, 
and that this field will contain, at object time, a numeric code representing one of the 
cities listed in the table. If the programmer writes move one.way (destination) to 
bill.amount, the system will obtain whatever number has been placed in the desti- 
nation field and will use it to determine which item in the table is wanted. It will 
then find that item and move it to the field called bill.amount. The reader will have 
noted that this number determines the position of data by the simple process of 
counting lines; the code numbers used, therefore, must be assigned in a sequence 
corresponding to the lines of the table. 

COPY 

This type code is used to copy a data description previously defined in the program 
so that it can be used again elsewhere. This makes it possible to use a data descrip- 
tion with new data-names and, if desired, new level numbers. 

The copy type code is used as follows: The new name of the data description 
entry is written in the "Data Name" columns of the new entry. The code copy is 
placed in the "Type" columns. The data description to be copied is specified by 
writing its original name in the "Description" columns. This description must already 
have been read into the system for the copy code to be able to operate on it. 

The processor will then obtain the original data description and copy it in its en- 
tirety, except for the following modifications : ( 1 ) The original name will be replaced 
by the new name. (2) If a new level number has been specified for the new name, 
the level numbers of the original data description will be adjusted so that they retain 

ui^ii \j i igincu Ji^iauuiisiap iu tut- iiain^vj i^iitiy. iiiua, ix uii< cnigmai ^iju^iiv,^ kjl iw^i 

numbers had been 01, 03, 04, and if the new name is assigned level 05, the other 
items would now be placed at levels 07 and 08, respectively. 

Suppose the programmer had previously written the following entries in the data 
description : 
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Suppose then that he wishes to set up an identical data description for a detail 
record, except that the new description is to have the name pay.rcd.detail and it 
will be placed at level 02. He could write the following entry: 



DATA NAME 



DESCRIPTION 



J_l ' I ' i I I I 



/>,#,¥>., f^il),. K o x ey-A\'\t-\ 



*z 
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The effect of this entry would be as though the programmer had written an en- 
tirely new set of entries in the following form : 



SERIAL 
4 6 


DATA NAME jj TYPE 
7 22 23"24 25 
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Quantity 
(Col. 31-35) 



LABEL 

The type code label identifies a data description as that of a label record. This will 
cause a redefinition of the label area in the input-output control system. The actual 
use of this code will be explained in the publications pertaining to the various Com- 
mercial Translator processors as they apply to individual machine systems. 

If an item of data will be followed by one or more additional items having the same 
data description, the programmer can avoid writing the additional data descriptions 
simply by specifying in Columns 31 through 35 the total number of times the data 
description is required. This number must refer to data items occurring in sequence. 

The "Quantity" columns may be left blank, and, in fact, usually are. In that case, 
it will be assumed that they contain a value of 1 , and the specified data description 
will be entered only once. 

Since quantity numbers are used to specify sequences of data descriptions for use 
in lists and tables, and since data in tables is referred to by the use of subscripted 
names, quantity numbers should not be assigned to data items not having names, 
unless these items include named items at a lower level. 

An example of the use of a quantity entry was included in the discussion of the 
redef type code when used to set up a table. (See page 75.) The reader will recall 
that the field called rate, together with its subordinate fields, was to be entered 30 
times. Accordingly, the value 30 was placed in the "Quantity" columns opposite the 
name rate. Since each of the subordinate items (city, one. way, round. trip, and 
excursion) was required only once for each rate entry, no value was placed in the 
corresponding "Quantity" columns. If, for some reason, one of the subordinate fields 
had been needed more than once, a quantity could have been specified. 

Quantity numbers may be specified for as many as three levels in a single "nested" 
group. For example, assume that a program must deal with five items called state, 
that within each of these are four fields named district, and that each district con- 
tains seven smaller fields called city. The quantity 5 should then be written for 
state, 4 for district, and 7 for city. The processor will then reserve storage space 
for a total of 5 state items, 20 district items, and 140 city items (assuming, of 
course, that the level numbers show the proper relationships among the three entries) . 
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Mode 
fCc!. 36) 



Justify 
(Col. 37) 



To call for any one item of data, the programmer must write as many subscripts as 
are necessary to identify the particular level. Thus, state (3) would call for the 
third item called state, district (3,2) would call for the second district field 
within the third state item, and city (3,2,6) would obtain the sixth city field in 
the second district of the third state. Subscripts are always written in descending 
order of level. 

The term "mode" refers to the method by which data is represented, such as the 
binary mode or the binary coded decimal mode. For the purposes of the Commercial 
Translator, the mode used in the arithmetic units of the system is considered to be 
the system's "internal" mode, although the system may be able to read data in other 
modes. 

Column 36 is used to show whether the data being described is prepared in the 
internal mode for the system being used. In that case, the letter I is punched in this 
column. Data punched in an "external" mode is represented by the letter e. Specific 
information on the modes available for each system will be provided in the publica- 
tions covering the processors for the various machine systems. 

Since a body of data may contain information in more than one mode, the mode 
is specified at the lowest level of data organization — i.e., at the level where the "field 
pictorial" is shown. (See the "Description" columns.) Thus, if a record at the 01 
level contains two fields at the 02 level, one of them in the internal mode and one in 
the external, there would be no point in specifying a mode for the record itself. The 
mode (or modes) of a larger unit is therefore a consequence of the mode specified 
for each of its components. 

The term "justification" is used in printing and writing to mean the alignment of a 
margin. Thus, the text of this manual is both "left justified" and "right justified." In 
data processing, the term has a similar implication, since it is usually necessary to 
specify that data be justified if the programmer wishes it to be printed out with an 
aligned margin. 

Actually, however, justification means a good deal more than this. Specifically, it 
refers to the placement of the data in a unit of storage. In many systems, data is 
stored in machine "words" of fixed length. Very often, therefore, a particular item 
of data will be shorter than the space allowed for it, and it may be necessary, if align- 
ment is to be preserved, to provide a means of filling the unoccupied spaces with 
non-significant characters, such as zeros or blanks, depending on the system. On the 
other hand, it may be desirable to fill all available space with data, so that more than 
one item — or parts of more than one item — may be stored in a given machine word. 
This is known as "packing." 

It is extremely important to recognize that justification specified for an input item 
of data — i.e., an item to be entered into the system at object time — describes the 
item as it already exists. It does not change the justification; it is used in informing 
the system where to look for the incoming data. Justification specified for other 
items, however, actually controls the placement of the data. It instructs the system 
how to handle the data when it operates on it internally or prepares it for output. 

The effect of specifying justification is as follows: If left justification is specified, 
the data item is stored, or will be stored, so that its left-hand character is placed in 
the left-hand position of the next available machine word. This may mean that the 
right-hand portion of the preceding word is left unoccupied. If right justification is 
stipulated, the data item is stored, or will be stored, to the right in the next available 
machine word, leaving unoccupied whatever portion of that word is not required at 
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the left. If no justification is specified, the data is packed (if it is incoming data) or 
will be packed — there will be no blank spaces between successive items. 

Packing makes efficient use of storage space, but it may make it more difficult for 
the program to obtain the items independently of each other, since the processor may 
have to provide for "unpacking." However, packed items can usually be read or 
written more rapidly, since the system will not have to process non-significant infor- 
mation. In general, if the programmer must be economical of storage space, or if the 
program calls extensively for reading or writing long sequences of data, it may be 
more efficient to pack the data. If a great many of the items must be obtained indi- 
vidually, however, and/or if scanning long sequences of data is not a common opera- 
tion, justification of data may be more efficient. The programmer should evaluate 
each case on its particular merits. 

Alignment of alphameric information, such as lists of names, cannot be specified 
in the field pictorial. If alignment of such data is required, it can be accomplished by 
the use of the "Justify" column. 

The symbols l and r are used in Column 37 to indicate left and right justification 
respectively. If neither symbol is used, the data will be packed, as has already been 
noted. 

Description The "Description" columns are used to show the length of each field of data, together 

(Col. 38-71) with its format. They may also be used to specify constants and the names of data 

and procedures, as explained below. Specifically, the following kinds of information 

may appear in Columns 38 through 7 1 : 

1 . Format characters. These are shown and described in the table below. 

2. Constants. 

3. Data names associated with the type codes redef and copy. 

4. The word library, followed by the name of a data description stored in the 
library. 

5. The words quantity in, followed by the name of a field which will contain a 
quantity when the object program is run. 

In a number of cases, a complete data description entry will require that more than 
one of these kinds of information be listed on the same line. For example, it is gen- 
erally necessary to show both the format and the value of a constant. In such a case, 
the various items should be written in the order shown above, separated by one or 
more blanks. 

Format Characters 

The format characters serve two functions: ( 1 ) They show the number of character 
spaces to be occupied by a field. (2) They show the kind of character that will 
occupy each space. The resulting data representation is known as a "field pictorial." 

If the item of data being described is one which will be brought into the system at 
object time, the format characters must reflect the format of the data as it already 
exists; changes in input data cannot be effected by the field pictorial. However, if 
the item is one produced as a result of the operation of the program — as in moving 
the data or performing arithmetic on it, for example — the field pictorial has a direct 
effect on the manner in which the data will be handled. 

With certain exceptions, which are explained below, one format character is re- 
quired for each data character for which storage space is to be reserved. The par- 
ticular format character chosen for each space prepares the system to receive in that 
space data of the type shown in the table on the following page. 
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Format 
Cncif cicf 6i* wtsciniiiQ and Lss 

A Any non-numeric character, including the blank. 

X Alphameric character (any character in the machine's character set). 

9 Any numeric character. 

8 Numeric character, to be replaced automatically by a blank whenever it 

is a non-significant zero. 

* Numeric character, to be replaced automatically by an asterisk whenever 

it is a non-significant zero. 

V Assumed decimal point. This character informs the processor where the 

decimal point is located, for purposes of calculation and/ or alignment 
of values. The symbol is not required for integers. The symbol V will 
not reserve an actual space in storage. 

True decimal point. This character will reserve an actual space in storage. 

S Scale factor. This symbol is used as a "filler" or "spacer" when the input 

data does not show the position of the decimal point. E.g., a field con- 
taining percentages from 1 to 9 would be represented by the notation 
VS9; this would assure that the values 1 to 9 would be interpreted as 
.01 to .09. Similarly, if a field contains values that represent thousands, 
each unspecified digit must be represented by an S; thus, the notation 
999SSS would provide for values from 000,000 to 999,000, even though 
the three right-hand zeros would not appear as input. 

$ Dollar sign. An actual dollar sign will be placed in the indicated position, 

provided it is not followed by the symbol 8. In the latter case, the dollar 
sign will "float" — i.e., it will be placed immediately to the left of the 
first significant digit remaining. 

True comma. This symbol will reserve an actual space in storage, to be 
occupied by the comma. The comma itself may be replaced by a blank, 
asterisk, or dollar sign, if the operation of a preceding 8 or * has re- 
sulted in the elimination of non-significant zeros to the left. 

+ Plus or minus sign, one of which will always be placed in the space re- 

served for it, depending on whether the value is positive or negative. 
(Compare with use of minus sign, described below.) This sign may be 
placed in a column by itself, in which case it will reserve an actual space 
in storage. Alternatively, it may be entered as an "overpunch" with 
either of the format characters 8 or 9, in either the units or high-order 
position of a field; in this case, a special space will not be reserved, and 
the sign of the field will be indicated in accordance with the operating 
characteristics of the particular system. 

— Minus sign, to be placed in the space reserved for it when the value is 

negative; when the value is positive, the space will be left blank. If 
punched in a space by itself, this symbol will reserve a space in memory; 
otherwise, it may be "overpunched" and will act as described in the 
rules for the symbol + . 

F Floating point number. This symbol does not reserve an actual space in 

storage; it informs the processor that the number being described is a 
floating point number. It is placed between the format characters rep- 
resenting the fraction and those representing the exponent. E.g., 
+ 99V9F + 99. 

( n ) A number placed in parentheses immediately following one of the 

other format characters instructs the processor to allow for that 
number of the character specified. E.g., 9(4)A(12) is equivalent to 
9999AAAAAAAAAAAA. 
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Examples 

The following examples indicate the range of characters for which provision is made 
by the notation shown : 



Notation 



Range of Characters Provided For 



All characters in the machine's character set except numerals. 

All numeric values from 000 to 99999. 

All numeric values from * ***.00 to 9999.99. 

All numeric values from $.00 to $999,999.99. 



AAA 

88999 

$888,888.99 

Constants 

A constant is a value, or a group of symbols, placed in the program for use without 
alteration, such as a fixed percentage rate or a lixed name. A constant may be placed 
in the system by writing a data description entry for it which includes both a state- 
ment of its format (using the format characters) and a statement of the actual value 
or group of symbols. The format is specified by a standard field pictorial entry. The 
actual value, or the actual symbols, must then be written on the same line, separated 
from the field pictorial by at least one blank. This value (or this group of symbols) 
must be enclosed in quotation marks. 

While a literal may be thought of as a form of a constant, the reader should note 
two distinctions : ( 1 ) Literals are written in procedure statements, whereas constants 
are placed in the system by means of data description entries. (2) Constants, unlike 
literals, must always be enclosed in quotation marks, even though they may be wholly 
numeric. 

To illustrate, if the programmer wished to place the percentage .05 into the data 
description as a constant, it would be necessary to specify the nature of the constant 
by a notation such as the following: 
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In this example, the notation V99 is, of course, the field pictorial, and it is followed 
by a statement of the actual value of the constant. 

Data Names Associated with REDEF and COPY 

When the type codes redef and copy are used, it is necessary to specify the name of 
the data item or area to be redefined or copied. This name must be entered in the 
"Description" columns. (See the discussion of those type codes earlier in this 
chapter. ) 

Library Names 

The word library, followed by the name of a data description stored in the library, 
designates a data description which is to be copied. Availability of this code enables 
the programmer to store data descriptions which are frequently required, so that he 
can save the effort of writing new ones when a previous one will serve his purpose. 
When a library data description is prescribed, the type code copy must be used. 



Quantities Specified in Named Fields 

It has been shown that if a value is placed in the "Quantity" columns, the processor 
will reserve space for repeating the specified data description until it appears the 
number of times indicated by that value. In certain special cases, the programmer 
may wish to alter the use of such an area at the time the object program is run. The 
storage area, of course, will already have been reserved by the action of the processor, 
and at object time it is no longer possible to set aside new areas. However, for certain 
specialized purposes, it is possible to regroup the components of an existing area by 
using the quantity in option. In this case, a quantity value is placed in a named 
field and the program is referred to this field by the words quantity in followed by 
the name of the field. 

This usage is not required in most programs. It represents an advanced program- 
ming technique, providing additional facilities which can be used effectively by a 
skilled programmer. While it is not the purpose of this manual to explain the many 
refinements and uses of this technique, its general nature is indicated by the following 
discussion: 

Suppose that a certain data description having the field pictorial 999V99 is to be 
repeated until it appears 100 consecutive times. Each iteration of the data descrip- 
tion will reserve 5 character spaces in storage, and therefore a total of 500 spaces 
will be reserved altogether. Suppose that this area is referred to by the name table. 

Suppose, then, that the programmer wishes to set up a number of different tables 
at different times during the running of the object program, using this same storage 
area for each. Assume that the first, referred to in this text as Table 1, consists of 
.iv/ columns and 10 lines — i.e., there will be 10 data items on each of 10 lines, and 
each item will have a field pictorial of 999V99. This table could have been set up by 
the original data description for the area in a series of entries such as the following: 
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Once the table is described, the programmer may refer to individual items in it by 
the use of subscripts, the first subscript referring to the item at the higher level. Thus, 
item (4, 2) would refer to the second item of the fourth column group. 

When the system is directed to obtain this item, it relies on a technique of counting. 
Specifically, it would rely on the fact that ten items are specified for each column. 
Thus, it would count off the first ten items, then the ten items of the second column, 
the ten items of the third column, and it would then count to the second item follow- 
ing. In other words, it would obtain the 32nd item in the string of data representing 
the table. 

However, it is supposed that at some other time in the program the programmer 
wishes to set up another table (Table 2) which uses the same field pictorial for each 
item but which requires a different grouping of columns and lines. Suppose Table 2 
has 20 columns and 5 lines. The programmer could theoretically write the following 
entries: 
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However, these entries would reserve space in addition to, not in place of, the 
original table. 

Suppose, however, that the programmer, in setting up Table 1, had written the 
following entries: 
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Suppose, further, that the names column.qty and item.qty are the names of 
fields into which values may be placed. In this case, the processor would first note the 
value of 100 in the "Quantity" column opposite the name item and would reserve 
space for a total of 100 items to be placed in the table. It would cause the object 
program to look in the fields column.qty and item.qty to determine the actual 
quantities for the entries column and item. These values would override any values 
previously placed in the "Quantity" columns. If the programmer wished the first 
table to have 10 columns of 10 items each, he would have to be sure that a value of 
10 was placed in both the column.qty and item.qty fields. Obviously, if Table 1 
were never to be replaced by another table, it would be superfluous to use quantity 
in entries, for the quantities could be specified directly in the data description. 

However, since the quantity in entries have been made, it is now an easy matter 
to construct Table 2. All that is necessary is to place the values 20 and 5 in col- 
umn.qty and item.qty respectively. If, then, the expression item (4,2) is written, 
the system will know that instead of counting ten items to the column it must count 
five. Thus, instead of obtaining the 32nd item, it will obtain the 17th, which is the 
one required. 

If the programmer wished to set up a third table in the same area, with four col- 
umns and 25 lines, he could place the values 04 and 25 in the corresponding fields, 
and, once again, subscripts written in accordance with the new table structure would 
be correctly calculated by the system for locating individual data items. 

General Note: If the description of a data item overflows from the "Description" 
columns, it may be continued on the next line, following the rules given for the con- 
tinuation indication column (Column 72). The break at the end of a line must 
occur between words, since the processor will assume a blank at the end of each 
line. Multiple blanks, however, are treated as single blanks. If a constant is to be 
carried over onto a new line, the portion on each line must be treated as a complete 
constant (i.e., enclosed in quotation marks) ; the continuation indication is not used 
in this case, and no blanks will be assumed between successive lines. (Note the ex- 
ample used on page 74 to show how a table of rates might be placed in storage.) 
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Cont. If the description to be entered in either the "Data Name" or "Description" columns 

(Coi. 72) (Columns 7 through 22 or Columns 38 through 71) is too large for the space al- 

lowed, it may be continued on a following line. So that the processor will recognize 
this situation, the programmer must enter a character of some sort in Column 72. 
Any non-blank character will suffice. The processor will then interpret the entry in 
the succeeding card as a consecutive part of the previous entry. 

A continued name must, of course, be placed in the "Data Name" columns, and 
an overflowing description must be continued in the "Description" columns. The 
rules for determining where the text should break between lines are given in the 
discussions of the entries to be made in those columns. 

Identification Columns 73 through 80 are provided for the optional use of the programmer should 

(Col. 73-80) he wish to place a code on the cards to identify the program of which they are a part. 

Any characters from the basic character set may be used, since the characters in 
these columns have no effect on either the processor or the object program. 



Storage Areas 



It has been pointed out that the internal storage of an electronic data processing 
system may be used to contain data of various kinds, including the program which 
governs the processing. As a result, those who work regularly with the technical 
aspects of programming are accustomed to thinking of different kinds of storage. 

For example, when an input record is brought into storage, space must be reserved 
for the original record before any processing is carried out. This may be thought of 
as an input area. 

Then, after processing begins, it is often necessary to move data from the input 
area into an area where it can be worked on. This is like moving a ledger card from 
a file to a writing desk where an entry will be made or a value computed. "Working 
storage" is therefore required in many cases. Actually, the registers of the system 
provide space of this kind in many operations, and since in these cases it is provided 
automatically, it is not thought of as working storage. However, in other cases, it 
may be necessary to reserve a specific amount of space as working storage. For 
example, a computation will sometimes produce intermediate results which will be 
needed later in the program but which are never needed as such in the output record. 
It may therefore be necessary to reserve an area in which to store such results 
temporarily. 

Another necessary use of storage space is for the assembling of output records. 
Normally, as each phase of a program is completed, the results will be moved to an 
output area until the complete record has been assembled. The various output fields 
may differ in format, size, and sequence from those of the input record, and data 
may have been added or deleted. Thus, an area of storage must usually be set aside 
for assembling the output record. 

Other storage areas may be used for reference data, such as constants, literals, and 
tables. 

The experienced programmer often finds it convenient to distinguish among these 
various kinds of storage. Actually, of course, all storage areas are controlled by the 
same basic techniques — data is always addressed by its location, and data in any 
area may be governed by any of the system's basic operating instructions. Since the 
Commercial Translator system eliminates the need for the programmer to keep track 
of specific storage areas, it also eliminates, for the most part, the need to distinguish 
between types of storage areas. Storage areas are automatically reserved when the 
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data description is written, regardless of how the area is to be used. Certain special 
provisions, especially those governing input and output, are built into the processor 
for each system, and these are described in the manuals for the various processors. 

The programmer, however, must be sure that all data-names required for input 
and output, as specified in the manual for the system he is using, are properly de- 
scribed in the data description. He should also examine his program to be sure that 
every item of data used in the program, whether as input, output, or for intermediate 
operations, is properly described. The processor will then make all necessary pro- 
visions for storage space and for identifying the data to be stored. 
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Appendix 1: 



Programming Example 



Introduction 



The Commercial Translator system is so designed that the programmer can analyze 
a business problem in terms of the problem itself, rather than in terms of the equip- 
ment on which it will be processed. He can rely on the processor to convert his 
source program into a machine program which will take advantage of the operating 
characteristics of the equipment. Thus, his first approach to a problem will be one 
in which he determines each of the basic steps needed to solve it, and the sequence 
in which they must occur. 

The basic device for showing the flow of information and the sequence of opera- 
tions in a simple form is the flow chart. In addition, a process chart will be useful in 
determining how data should be grouped for input to the system and what data 
groupings are to be obtained from it. From these two charts the programmer can 
proceed easily to writing the source program itself. 

To illustrate these three phases, the following pages contain a flow chart, a process 
chart, and a sample program that could theoretically be used for a simplified payroll 
operation. This program is intended only to illustrate the general method of using 
the Commercial Translator language and to show how the data to be used in a pro- 
gram might be defined in a typical data description division. It is in no sense an 
attempt to demonstrate an ideal solution to a payroll problem. 

As the process chart shows, there will be two input files— a master file and a 
detail file. These will be on magnetic tape. The output files, also on tape, will be the 
following: (1 ) An updated master file, which will be used as input in the next run- 
ning of the program. (2) A payroll report file, which will be used to produce a printed 
report. (3) A check file, which will control the printing and punching of pay checks. 
(4) An exception, or error, file, which will contain any master or detail record for 
which no matching detail or master has been found. 

Both the master and the detail files consist of individual pay records for each 
employee, arranged in ascending sequence by employee number. It is assumed that 
there will be a master record for each detail record with the same employee number, 
and a detail record for each master record. Any exceptions will be given an error code 
and moved to the exception file for subsequent correction. 

Each master record contains, among other information, hourly pay rate and year- 
to-date totals for gross pay, retirement premiums, and insurance. Among the items 
included in each detail record is a statement of the number of hours worked during 
the current pay period; this, together with the hourly rate in the master record, is 
used to compute gross pay. The records also contain other data, such as employee 
name, department, information to be used in performing withholding tax, fica, bond 
deduction and other computations, and so on. 

Each of these items of data is named and defined in the data description portion 
of the program, in accordance with the rules given in Chapter 4 of this manual. 

The actual procedure statements, which in this case are written before the data 
description entries, follow the rules given in Chapter 3. The program begins with a 
renaming of data items, using the call command, so that they can be referred to by 
abbreviated names. It then proceeds to a comparison of the employee numbers used 
to control the processing, and the reader will see that provisions are made to transfer 
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to various routines (using the "conditional" go to command) depending on whether 
the numbers are equal or unequal. 

The sequence of procedures from that point on closely parallels that of the flow 
chart. As the reader will see, the program contains a number of complete routines 
which are performed when necessary, regardless of the sequence in which they appear 
in the program. The go to, do, and begin section commands are used to call for 
them. 

While this program is very much simplified, it does illustrate many of the basic 
techniques used in programming. The reader will find it helpful to review portions of 
Chapters 2, 3, and 4 as new concepts are presented in the procedure statements. 



Process Chart — Payroll Example 
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Flow Chart — Payroll Example 




File Grand 
Total in Pay- 
roll Report 



Close All Files 



Stop 



89 



Set Low Detail 
Errorcode 



File Detail 
In Errorfile 




Compute Gross 

Pay and Bond 

Purchase 



Do FICAand 
Withholding 



Search Insur- 
ance, Retire- 
ment Premiums 



I 



Calculate 



Update Master 
Record 



Set Low Master 
Errorcode 




Accumulate 

Dept. Total and 

Grand Total 




File Depart- \ 
ment Total in ] 
Payroll Report/ 



File Pay 
Record in Pay- 
Report 



roi 



7^ 



90 



IBM 



COMMERCIAL TRANSLATOR PROCEDURE DESCRIPTION 



CTL. 
1 3 


PROGRAM 


SYSTEM 


PAGE / OF / q 


PROGRAMMER 


DATE 


IDENT. 73 80 

1 1 1 1 1 • 1 1 1 


SERIAL 
4 6 


PROCEDURE ! TEXT 
NAME 1 
1 
7 12(13 72 


°\ / l 


1 

^r x P/?,£> x C-,£yb { (/,i^ K t, , | | | , | | | | | | | | | i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i 


*,*! 


, , , i , jc,*.*^. ^kvVi'iV^i.,/^,^,^,/?!), , ,^,'V,*,/i<Vi,, , , ,,,, i i , i ,,,,,,,,,,,,,,, , 


X 3 \ 


i iinj in i ifi^Vi^iA^iA^i'Vi^i^i,)! ill, x e x o x /v x b^^ x t/ x t x r x;x , i i i i i , i i , i i i ,, i i ,,,,,,, , 


*>V\ 


i I I l I (\6\0\V\l>^M6\W\l M^r^iO^i)) , X /3 X X /V x l>^ x tf ,£>,**,, i 1 I I i i i I i i i i I i , i ,, , , , ,, i i , 


°\*\ 


i i i i i | ( x 6 x x /l/ x M x 4 x C x e x l//f x e/ x 4. x A x r x ' x O x fl/ x ) x ,B,0,/l/,t>,A,<l,(L,(/,W,,, ,,,,,, ,,,,,, , 


0,6, 


i i n i | i i i i l ^ l /|/J<-r 1 ^,/f|/? l /^d l ^ 1 . l /' l /? 1< f l ^ l , , x / x V x S x P x A x £ x M XfX , , i . i , i , , , , 


0\1\ 


him ii i i Yi^ifr"i7 r /i^i6-K«/,^ l /*',r„|/'i^,^,^i / ) l , x ^ x e x T x ^ x e x M XfX , , , , , , , , , , , , , 


o,$, 


minimi x(^\ef\fi\*\T x « x ew x r x . x T x 6 x T,A x i.x) x x d,p,t,., ,,,,,,,, ,,,,,,,,,,, , 


'l?l 


S,T,£) { tf,T\>.\ , x O x /° x e x M X A\L\L X \f\l \L\£\"S\,\ i i i i i i i i i i i I I i i i i I i I i i i i i i i i i i i i i 




1 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


M^l 


6i£^./t x 4\f i T x £ t /? x * i , x 6r x £ x r x t At x /r x s x r x £ l * X9l , ,/l,r, x £ x a/J> x x t> x o x x £ x /i/ x 2> x . x o x p x .^ x /i x 5 x r x £ x /z x s x . x , , , , , , , , , , , , , , 




i 

i i i i i 1 i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i 


n/i 


^,e,r„,D,^r x /q,/ x c x . x i X 6 X £ X T X x t> x £\T x d x t x i Xr , , x /i x r x x £ x /i/ x J> x ,£,*, ,7^, x £ x As,D,. x d x F x . x b x e,T x A x j x t ,s-,. , , , , , , 




1 i i i i i . i i i i i i . i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i 


/,£, 


4^i^/^|/fj^i.i£>/i*Vi0i/^"ifi . \W\U\M\6\£\«\S X .\ | x tr X O x x T x O x x C x 0f4\P\0 x T\€ x .\P\rt x y x x k/^\£\A/\ x b x 6 x T x A x / ,t, x x £ x M x f\£. x x Y x # x O x 


/ l^i 


,1,11 |/,Xi \£ x & x U x 4 x k\ \T x O\ \M\*\S-\r\£\t> x \£ x M\£> x /L x O\Y x Yl/\0 XTX | x /L x 6 x V\.\b x £ x r x A x i\l. x X t/ X H\£/Vi x b x £{f x A x l X L\ , , , , , , , 


'I**! 


, , , , , \e x MSsL x O x Y x A/ x O x X / X S X x l x £\S\S x x r^^A/ x H\A x ^<r x £ x ^ x x £ x V x f x L x Oy x fi/ x O x . x ,,,,11, 




1 

1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 


/,*", 


^ /, <£-,//,. ,z>j £, r, ^|/,^ 1. 1 i x M\o x i^\£ x , \h x ', x r x o x ,/*?/?, s-|7-,<f I*, x e x * x A x oA x c x o x b x € XfX , x * x / x c x £ x x m x 4 x s x t x £ x « x ,/,/if ,,,,,, 


/,£, 


1 1 1 1 1 \£\#-\ A >\°\ f ^\»\ f:i \ , .\ l -\E\m\ | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | , 


'l7l 


. i . i i J , x o x e x r x x w x f x T x e x K x}X , x a x t x ,£i/*f/>i x o x o x x £ x /v x 6 x . x o x p- x . x /i x 4 x s,r x £ x x,s x . x ,,,,,,,,, , , 


/.tfl 


, , i i i I i x 6 x t> x iTi^i x e x O x A1 x f x A x A x e x * x £\*1 x / l, x Ji x ot/ x E x e X X *' x (f x rt x 6 x £ x * x S x . x i i i i i i i i i , i i , i , , , , , , 




1 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 , 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 




1 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 , 1 1 1 I 1 1 1 1 




1 

1 1 1 1 1 1 1 1 1 1 1 I..] 11 1 1 M I..M. MM J 11 1 . 1 1 II INI 1 1 1 1 1 1 1 1 . 1 . .1 1 1 1 1 l 1 1 1 1 l I i i i . i i | i ,_., i i 



IBM 



COMMERCIAL TRANSLATOR PROCEDURE DESCRIPTION 



CTL. 
1 3 


PROGRAM 

SAMPJLJE PAVA.Oi.JL 


SYSTEM 


PAGE g 0F /O 


PROGRAMMER 


DATE 


IDENT., 73 

1 1 1 1 1 1 


ao 

i 


SERIAL 
4 6 


PROCEDURE ! TEXT 
NAME | 

7 I2|I3 


72 




i,i,, \£\X x R x 0\X\ -\F\/\ L { £ i A i i i i i i i i i i i i i i 


x t> x £ xfX , x ££££ x x D,e(T/J x l x L x ,/,/f , , , , , 




i i i i i i i i 1 i i i i i i i i i i i i i i i i 




1 1 


.1 J.l LL . |__L..i^l^l_iTL^i . L^lTj»iA^|7"|/7|/ |/ |«| | | | | |. i_.l_I._L.J_. 1 .1_1 
l 1 1 1 1 l I 1 l I I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ,1 1 I .1 


i i i i i i i i i i i i l i 1 i i t 1 i i i i i i 




i i i i i i i i i i i i i i i i i i i i i i i i i 




'_L*L_ 


£ x r l 6 x . x x £\. x M x A x S l T [ £ x ft x S [ . l i ,/,/*, ,£,£,71/*,/,/, x £ x V x P x l x x V x /Y x x ,-, ,",/,<*,//„ .K.tf,/ ,<r,£, x T x H x £ x tf x i*.^ .Titf, .... 




(3, 5", 


, , I , , j^i/^i.itf,/ 7 ,.!/?!^ .i..j^i^|V|tf|/€|A^/,<-|^, |JS-|£|7-, |/^^5-|r, /",/?, i^,/*/,^,/.^,"/,^,^, , = , ,//,/,£,//,,,/,,*,/: ,^,/F,,, i i 






1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ! 1 




*L<*.L_ 


£ x /V x t> x . x x P X y x C) x £ x T x £! x J x j. x S\. x , t/|/-| x Af\A\S x T x £\A\ \£\M\£\£ i^i/|/T, X ,«, x // x /,*,//, . ,/,*,/ X U X £ X \T^ X £ X /V X x & x O x X T^ X , , , , 




*,7, 


, , , , , j^,/),,,^.,/?,*/^ , x O x T\H s £ K *Ml x S x £ x X 5 X £ X T\ x l> x £ x r x A x / x /i x 


\*W{\*\*\r\°\ ri i^l'i 

.1 .L. L J . 1 U _i 111, L L-..1 

_L_L_L. J I _L 1 L. l._L. L .]_ i_J 


*M.S x A x l x i/ x £„, , x 6r 


°\ 


4*i 


i i i i i j^'i x C x o { fl7 x P x /i^ x £ x ^£/tf x fi x L^o x v A £ x £ x . x Ar x cy x fli x 6 x £^ x s x . x , , , , 


1 1 1 1 1 1 1 1 1 1 1 


1 


i i 


i i i i i j i i i i i i i i i i i i i i i i i i i i j i i i i i i i i i i i 


1 1 1 1 1 1 1 1 1 1 1 




4.7j_ 


^//■A.i^j.irf.W.'i i \rhW\Z\ x ts0\#^£\s x r x 0\/v x a x , x /v x 6 x x 6, x k x A x /V x o x . x t x o x t x /} x l x x r x o x x £ x £i x v^ x £ x c x o x rt x D xf , , x £ x / x t x £ x 




'\°\ 


i i i i i \ / *\ /:i AY\rt\£\C\ \ / Z\ £> \i\ l .\£\£\£>\S\£\ \/3\A.\l\ \£\/ x L x £\S\m\ \ i i i i i i i i i i i i i i i i i i i i i i i i i i i i 




'.'i 


I | | | 1 1 1 \5\ ,/ I.^L. / 3.... l/i^J. .^I ^f * 1 1 1 1 1 1 1 I t 1 1 I 1 1 1 ! 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 1 1 1 i 1 1 | 1 1 1 1 I 




l i 


i i i i i 1 1 i I 1 i 1 I I I I I 1 I 1 1 1 1 I 1 1 1 1 1 I i 1 I 1 1 1 1 1 1 I 1 1 I 1 1 1 1 1 1 1 1 1 1 i : I I l I l i i i 




'i*L_ 


^/^/^irj^fi.i/Vivvi i i/il \t>\£\T\A\'\L\ \//\t>\i/\*\S\ |/|5i x & x A\e x A\T x e#\ \T\#\AM \¥\*\ \f\#\*M \S\f\-r x x o x £ x r x £h/^ 




/A. 


i i i i i \*itfi* iS.i?\ a~.i \(\°\£iT\Al\£\_\«Y0\O r \*&\ i-i \^\o^}\ ,*i \*\A x f x r X £r# x \*\A\T X £ X I*, ,/|.i51.i , 




, , , , , I , x s x js x r x x D\£ x r x a x / x i x x 6 x x x C\S x s x ,-, x o x £ x -r x a x / x L x x 6 x /? x o x $ x s x ,+, x M x 4 x s x r x £ x £> x x ^a x r x e x ,*, ,>/,<?,,, , ,/>,<?, 




/.7. 


, , | , , \f\/\C\ti x „ x /Z x O x (/ x T^ x fl/ x £\ ? i , ,/>,*, x *>\{ x T x M x O x L x D x t x /V- x 6 x . x T x /l x X x .\/Zs:6 x U x T\/ x fV x £ x . x , , , , i i , , 




inn. < i /./=■. \M\A\S\T\£\A\ \6\t\M x i> x € x biV x t x T\ i/i5, x A/ x d\T x x £ x a. x l£ x fi x L\ X T X D X x Z x £ x K x O x X T X « X £J/ X x b x d x ,,,,,,, 




1 i i i i \8\A x fl/'\I)\, \/?\£>\t/\T\i \/V x £ x . | i i i i i | i i i i i i i i i i i i i i i i i i i i i i i i i i , i i i , i , , , i i i 




U, 


i i i i i j i i^i^i \5\E\#\X\C\H\ X £ x £ x /K x x / \/V x b x £ x X\ , = i i/|/i/i ) i /,^i .j i i i i i i i i i i [ i i i i i i i i i i i i i i , 




3'i 


t i i i^./vr/-, ,--, x o x £ x r x n x / x i x X K X £ x r x / x * x e x v x £ x fi/ x r x ,-, x d x £ x t x m x/ x t x x / x /v x s x (/ x ^a x ju x c x £ x ,-, x t> x e x T,# x / x L 


LL 

i 


i i i i i i^i^i^i^i/fi^i^iC.17"! . i i i i i i , i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i i j i i i i i t i i 
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SYSTEM 
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PROGRAMMER 


DATE 


IDENT. 73 80 

1 1 1 1 1 1 . 1 1 


SERIAL 
4 6 


PROCEDURE ! TEXT 
NAME 1 
1 
7 12)13 72 


"i/i 


1 

mini A^, .^/e.^tf.s,/*,*?,/^,/^! ,^,-f, r^,/ ,/, , /", <?,r,^ , 5, , 7", <s>, 1/^,5-, r^/f, l r i a l r^£ i s lrl , MO x C/ x £ x , , 


'i*l 


, , , , , j^^/e^^j'^^,//,/),/,^^ .^r.^/.z, ,r^, ,/V,/,^,^ ,<?,/?, 


A/J_l_ lAA€A *i *..L._LJ /V J A 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 


*-,*, ,/v*iVi*i^i'i*.A i 


^,5, 


i i I l i jrf^.r, />,/?,/, ,7]^, x l x tf x £\C\K y \AM0,£f x /V x T\. x i i i i i | i i i 


i i i i i i i i i i i i i 


4^1 


i I I 1 I 1 I i/ 7 , /|/L|<f| \C\A/\£\C\K\'\ | i | i i i i | | i | i | i i i i [ i I i l I i i i i I I i i I l I I i l i i ! i i i i i i 


'l^i 


>,ii,|, ,/,^, \P\A x V\M\CxO&£>\ x O x £ K fi\A\fi x Trt£MT x X / X S\ \<Sr\*&\A\T\fAi ^//^M x C x (/^/Z x £^r x x D,e K P,A^(T /f x £^f 


4^1 


, , i , i jr.^./K ,/^^,^i^, i^iz.^^/r,^ ,r-,^, ,/^,/i/tf, <*",£,*,*, a, x £W\/L x o x y x /v x o Xfs ■ k^i/v^^i*,/*,^, MA x w x £ xfx , , , 


ff \1\ 


, i i i i j/^,^1 i^i^i/fi^^ij-i/^i^i/j/i^i/i/K^i \C\£\f\A\#\TM**/\'r\.\r\c?\r\4\£\ \r x o x \£ > \4\V\*\*\&\0\*\i>\4\ i \£\/\/.\£\ , i , i 


°[*\ 


, , , , , j/Vi/^^i/eiA.i i i^i^i |3 ?,*v?i0,s, i 7 !^, i^^r, ^.^s-,,, , ^r, i^/e^ris-,,, , ,^,^,r, M#^ t[ , 


*\9\ 


j^.^ir; ,/ViO^.i , i^i^iri \6\6\nr\0\£\D\i/ x c x r\ r \ i i*>i/°ir, ,/, 


AfiS\P\X\£\Wr\ i \J>\I°\T\ i/?i 

. 1.. L..L 1. 1 1 1 1 1 1 1 1 1 1 


€\T^X x £M fX i .0,/°i7-, i 


/,©, 


, , , i i Wx£xTx^A</x. x i ,£,/», 71 x 6\0j/\l>\PMfiiCiH x ft\S\€ x S x ^ , , , , , 


i i i i I 1 i i i i i i i 


'l'l 


,,,,,!, ,/^,^<f, \C\0\fi\*. x e x s x P x O\Mi>\i ^6x lA^ri^/iZ, ,7;^ ,/r^,//f,<r,t^ 1 /e,^> 1 , 1 x cma^<tmT\,\ , i^ii>, 1 , , , 


'l 52 -! 


, , , , , j^^/^/p^ir./^i/^zv 1/1^^1 i^i^iri^i/1/1 i^^i \O^^ x /j^r^\£\^T\'\r\0{r x /}\i^\ , ^/e^i/n^i-ir, 0,7^1^1 , 1 1 1 


Vl 


,111! i/Vi^Kfi i/i/^iKi/^I^i^i^i/Pi^i # | [ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 i 1 1 1 1 1 1 1 1 [ 1 1 1 1 i 1 1 1 I 1 1 


'l^l 


1 1 1 1 1 1 1 \6\0\ \T\0\ \£\£~\T\. MA\5\T\£~\/?\ *\ i i i i i i i i i i i i i i j j .1 .1 i. i 1 i 1 .1 .1 i i i i. i i i i i i .j_.._l_i ...i jl 


1 1 


i i i i i 1 1 i i i i I i i i i i I I 1 I I 1 I 1 1 1 1 1 i i I i I I 1 I J 1 I i. .1.. ._ i t _I i J_ 1 1 I l 1 l i : i I l i I i i l. J J . 


/l 5 ", 


Z 7 ! /i£i^i„i>?j <?i^i 7*1 /i/i/irf'i.i i \&\£\£-\/\M \S\£\C\T\/\OM,\ 1 I 1 i i i i i I I i i i i i 1 i I 1 1 1 i I I i i i i I i I I I I i i 


/,£, 


, , , , i | i \/\F\ \Af4\S-\T\&\A\ \fi\/\Crf\ I-/, \0\.\0\S\ i*i \D\C\r\0\j\L\ \6\K\0\S\S\ |/|5, \t\f\S\S\ ,r\//\^f\M \/\#\4\.\0\0\ i 


/,-7, 


,1,1, \r x // x ew \S\£\T\ ^£cr^/\C\ \P\/\C#x i-i \c\.\0\3\ \*\ \t>\£\T\a\/ X L\ \&*\a\S\S\ i x o x r// x £#M/ ,r ,<<?-, & x £ x -r x , , 


'|f| 


i l i i I \D\£\r\#\/\/\ \£\/\d\*?\ i="i \t\4\4\.\0\0\ i-i \M\A\S\r x £~ x A> x \f x / x C\4\m\ I I i ! i i I i i i i i i l l l i i l i i , i I 


'l?i 


iiiiii \4\l>\&\ \£>\£\T\4\/\£.\ \f\' \C\4\ \T\0\ /^\^S\T\£^\ \P\/\Q x ti x *\ i , , i i , , i i i , , i i , , , i , , , , , i i ■ 


.z.0. 


i i i i , \£\/l\l>\ \F\/ \d\d\ •]/?[£{{/ \~7\/ \As\£\ »\ iiiiii i .j j.j j._i i , i i i i i i , i i i i i i i i , i , i i i.i i,,,i i i. . i i i ,j 


I 1 


, i i i i | , i i i i i i i i I i I i i i i l i i i i i i i i i i i i i i i i i , i l i l I i I i l l i I i i I l i i i l i l i i 


1 1 


I i i i i 1 I l i i i i i i i i l i I l I i 1 I 1 l i i i l l I l I l l 1 l l 1 l ] 1 I 1 l 1 1 1 1 i i i I i I i i i l i l i I I 


1 1 


i i i i i i i i i i i i i i i I i i l i i i i i i i i i i i i i i i i i I i i i i i i i , i l i , i i i i i i i i i , , i , , i i 


1 1 


l 

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 .1 1 1 1 . 1 1 1 .1 .. 1 . 1 J . 1 1 1 1 1 1 1. . 1 1 .1 .. 1. 1 1 1 . 1 .-.I J 1. .1.1 111 1 . 1 .. L . 1 . J . 1 . 1 
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______ 



PROGRAM 



&/J/f*PL£ /P/7 //f <?/ 4 



PROGRAMMER 



V 



OF 



/O 



IDENT. 73 

-,, 1 I 1_JL 



PROCEDURE 
NAME 



I2|I3 



_____ 



■^■iZ^^^^^.^i-i^i^i^ir^i^i^^^^.^. -. . ■ <?.*•. *■'■>"■ x S x £ x C x T k / x q x m x . x ,,.,,., | | ,. 



_L J L 



J — I I I I L 



_!.___ 
_Jl_l 

_____ 
_____ 
I L 

V°ili. 

4^. 



j_ .i_____ 4_j iM _i / l J i 1*1 i^i^i-^i ^i^i^i i ^" ! A i <F|^|/ g i r, / ,<* ,/y, 5, ,/,,, ,_-,_ - , s,.s-, ,77*,*,*, ^^r^/ ,_, , _yf,<?,.-,s-, ,7yr,_v»; 

_L J_L_L 1 |- 5 l f l 7 'l 1^1 7"|>?I _1_L 1*^.^1 g__ l ^ l - l ' l * ! 1 * 1 J^T-flg,*, ' 1 *l l*!*^^ I^l l~l |/|~ l 1*1 1 *1*1 -*"l 77*7'. I I I i I 



J L 



_L 1 I i L 



4__^_j^L_rL__i__i^] SiJ.\ \Q\r\H\£\*\V\'\Sxe\ x s x e x r x x p x e x r x 4 x / x l x X A/// X r x ,- r &e x x x o x s x - 



_l uj.i | i i/fiA^i \1>\£\T\A \ / { Li M#\T \ \T\ 6x x / t f x # x S' x T x f x /?s ]_*_*!,?_. i i i i i i i i i i i i i i i i i 



-J I I I. 



__1___J_J I 1 L 



_JL_J L 



J I L 



______ 



J L 



_L1 L_L_. 1 



1_L_L_L 



J_.L1__L 



J_ 1 I I 



_L_LJ I J I ! L_JL 



±^±„ L_L_L 



______ LJ__L 



^^^^.^l^^.r,/,^-,., | Ae^/M x s x £,c x r x / x o// x . 



._L.__L_L__ LJ__L_L_J L 



_L_L_ 1 1 I L_L 



J 1 I L 



-LL.1 i |_i ±4&0l-j?Ml<s:iZi£j&l \S\Q^ x c> x € x d x c/,c x r x x r x o x /f^ x s x r s e x ^ x x o x /i/,i> x /} x c x a x v x /f x . x , , , , , , , 



_LJL_1_ 



______ 

_jl__±. 

A__ 

U___ 

/____ 
/i4 



Zl___ 

__*_. 
/ f 

_7'_ 

L___l_ 



6\*\")fi\-iC\4\ix x £//.\fi i r x /\0M. x i 1/1/7 ^ixr ^rj^vr, x 8 x a x A/ x J> x e x /i/ x 0fi x x / x s x ^\t>\T x x 6^ x e x /ir\e\«x sT/ //t x /r x ft^f j-^^ 



i— I.-I i-.j.^i^i^>i^i.^L^i>yi iTWv*'! i/i^i^i •y^.i'iT-,^ ^ _ l ___l^A^jA^i*. ,-, /f,4 x S{ r,eAx <B0MJ>Aew/t x ,-, 

\Af,4 x S K T,e^ &0M6,£- MdM ^ x r^£T\XM/ x S x £- x x 6r,O x ,ri<?, i^, ^/),.,^^^,. 



J. .1 L__J I . 



J_J 1_J I I I i I 



_ _l lj_l_j _J_jl i^i^i^^i xWA Axe^xW^xfixt \#\*\ **A\S \T X £A\ 1 77*i ,^1^1/t^^i^i^i^^ i,, i i^A^i Y i e x /v y fi l 0Aifi\£'A\ i 



_l .i l__i i j^i^i^i^/, iTj^i .^Vi ", \S\0 MI> x f x </ x /!iC x // x 4 x S\£ x 5 xr i r^i^-T, x 8 x O x A/ x fi j x X>J> K es>, &# MA^W/f, ,r,^ 



-J. i i_i . J . [„_.^i_j___^__^i_7__ 1^1*1^1^1 ^*1^1*1 i |/ r i/|£ i£ l \ 6 \ \#\A\*\*\J>\ *\A\ i/i/gf ifi/ei/fi^i/g,,,^/^,^^. 



_LJ I J I L 



-J I 1-...1 , I L 



1- L.LI..J I I 1^1*1 I 7 !*?! |g|*l ^lA»l^l^ l^l ^l^i^l^|7 r |/|g|^ f,| I i i i I I I I i i i i i I i 

^ 1 ^ j ^ l -jCJ^^lm_l j_^____i_ ^i^Ah ^i^/,/^.?-,., i iiii.i i ll!,,,,,, 

I 

. J — I — 1 — 1 — ( — I- I I I JJ-U 1 . . 1 — I — J . J_J L_LJ L_J I IIL ..L_J J. . L._ LJ. I _I_J_1__L_J_ J_i_.. 1__I 

__l____j__gL_^_[__l. !_!__. _L_1_J__L &€& r \ ' \ \ n/ \ » \ I I I I J_L.LJ J L LJ I 1 I I I I I I I I I I I I I I 



I I l__L 



J_L_L_L 



_1_J_ 



_L_L_L 



I I 



_1_J L__L_L 



J L_J_ 



J- i i I i 4-i . ±U^-£te£iX£&^&r& \ * \T\ i^i^A^/i^^/^ A* X T X € X \(\*M* \€tfJ\ W X (TM >*>*, l r^ i , , , 



_ _j_ i-i^^^^i^i^i^i^i^^^L-iAr^^i^^i^i^i \4\&\fi\.\T x /i x 6 x c x E x . x / x T x e x * x y^sS/Cerf x (j x vj>£\x x y x r x o x , 



i . i__^iT_^L_L_Zi^^ x fi x £ x T x P x * x e x xi x x(y/^t> x ejc x ) x x r { o t ,z>,f,r,/?,/ 

_L L-1-1_J 4 / Jl lf l 7 "l / {X^&fATlll-A- \^^±^LL^J±AlL^J-l.A.. 1 L_.l_l .. 1 _L.l_LL_L.i_l.J_.U_l_l_i.l_J 

■^ £ , A \ A £fi±Zj£± W \ Q X - \ I \£\M\f>\ \ 5 \£/l\&\t\M x » |_j [ | | | L-L I I X_l. 1 _L 1 1 I I l I I I l I I I I I 



..i_i_L_i_ 
A I I __L 



-L___L.l._J L__L 

J_J L.L_1_J L 



L.l_i___L.J L_J I I L 1 I 1 L 1...- L I— L-JL 



J I I I I L 



J I l__l L_J._J I i L... 1 I L 1 L 



J — I L-L-J—L 



-___.__ I I L-L 



-1 I L 
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PROGRAMMER 
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IDENT. 73 80 

._. ! . 1 . 1 L 1 1 1 


SERIAL 
4 6 


DATA NAME 

7 22 


_l 
> 

UJ 

23 24 


TYPE 
25 30 


QUANTITY t 

; 
31 35 i 


>• 

i| 

6 37 


DESCRIPTION 
38 71 


1- 
z 
o 
o 

72 


<Vl 


#i^ l^l 7"l^l 1 ! 1 1 1 1 I 1 1 1 


I 


I 1 1 1 1 






1 1 1 1 1 ! ! 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 




'.*» 


HAJxr^Ax i 


l' 


g^C^fl^ 




£. 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 i 1 1 1 1 1 1 1 1 1 1 1 | | | | ! | 




'<•?! 


i^^i/fi^i/e^K?,^,^, , , i i i 


1* 








.1^.1 1 1. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 


._ 


°\*t\ 


b\AxT\4\ i i i i i i i i i i i 


1* 






-- 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 | 1 1 1 1 1 1 1 1 | I 1 | | 


0\S\ 


^/ti^/L^y ,6f^„ Ml//*t x 6f/t 


h* 






1 1 1 1 1. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 


6\ &\ 


, ^ff^fixTMSMTi , , , 


1* 








?,?, . .... 1 ............. 1 ,..,.,,.,, , 




*\1\ 


i .'W./.'.v.r,*, , , , , , 


1* 








*l ^1^1 ?l 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I I 1 1 1 1 1 1 




'<?< 


\rt/ s d^6[ i i i i i i i i i i 


1? 








A \f\ / \ S 'J 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 l . 1 l 1 . | I | I . I 




'.*■ 


| /€|/?|7' |< S r | | | | | | | | | | | 


£ 








*.*.". *!*■*! . ,,,,,,,,,,,,,,,,,,,, 




/■'. 


x i>\A\~f\G\ 1 1 1 1 I 1 1 1 1 l 


!•* 








1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 . 1 . 1 1 1 I 1 1 I 1 1 




/,', 


■ m*xMtm i 


I* 








% ' 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 I I 1 1 1 . 1 I . 




'i*i 


i \£>\A\S\ iii i i i i i i i 


1* 








^I?! 1 1 1 1 1 1 1 I 1 1 1 1 I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 




/,3, 


i tY\^A^\ i i i i i i i i i 


1* 








?l?l I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 I 1 1 1 1 1 1 1 




/.*. 


i f i x l ffi/qs l -r ] / i .0MS' l i i i i 


h> 








?l?l 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 




/,*", 


i 7 "i< ? i" r i / ^|S'i i i i i i i i i 


h* 








1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 




'.', 


i i^/^i^i r,s*i i i i i i i i i 


1* 








*,*,*,?,*,*',*,* I I , , , , I ,,,,,, I 




'i*i 


, ^frtz/erf/iSMri , , i 


1* 








Ws"fi\1\ III............ ,,,,,, 




/,* 


, i/MSMKA^e^ , , , , 


1* 








www, ,,,,,,,,,,,,,,,,,,,,,,,,,,, 




'\1\ 


\P\/\ C \A i i i i i i i i i i 


iJ 








'i*,*.*'.*.?. . . ....... . . . , ....,, 




Z\Ox 


!* / l / ^' r | 1 1 1 1 I 1 1 1 I 1 1 


tf 








*.*.*.*.";*,*■ ...........,.,,.,,.,,..,,, 




*/. 


SxeMb&bxV&Ti/ x OM , , , 


l? 








Wi*.7. ■ ■ 




*i*i 


<?, <?, /tf^^i tf, d i ^,/^ £/,/: ,/7| -/;/ ,0 ^ 


i* 








'\ i\ ' i ^i ' 1 1\ i i i i i i i i i i i i i i i i i i i i i . i i i i i 




^1-7 1_ 


^j¥jW ^1 '&*_&/ l^l 




. LJ L_J l_ 


I. ..J 1... 1 . 

1 ! 1 I 




WA^Ml l_l_J_I_.i_l_L_.L_l__l I..W--J ~L 

A\d\d x 1 1 1 1 1 II 1 


1 1 1 1 1 1 1 1 1 | | | 


— 


z,y; 


1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 






1 1 1 1 1 1 1 1 1 1 1 1 1 I 1 1 1 1 


! 




1. 1 „. II .. 




1 .. 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 1 ! I I 1 1 1 1 1 1 1 1 1 1 
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7 22 
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TYPE 
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£ DESCRIPTION £ 

g 8 

3^7 38 7I72 


A /, 




,/ 


/Z^d^^fb 




4 1 1 1 1 1 1 1 


J l_l _]... 1 1 1 1 1 1 1 J..-J — L 




i Z\ 
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SAMPLE PAYROLL PROGRAM - MACHINE LISTING 



SERIAL NAME TEXT 

01001 *PROCEDURE 

01002 CALL (EMPLOYEE. NUMBER) EMPLOYNO, 

01003 (BONDEDUCT I ON) BONDEDUCTt 

01004 (BONDENOMINATION) BONDENOM, 

01005 (BONDACCUMULATION) BONDACCUM» 

01006 ( INSURANCE. PREM) INSPREMt 

01007 (RETIREMENT. PREM) RETPREM, 

01008 (DEPARTMENT. TOTAL) DPT. 

01009 START. OPEN ALL FILES. 

01010 GET. MASTER. GET MASTER. AT END DO END. OF. MASTERS. 

01011 GET. DETAIL. GET DETAIL* AT END GO TO END. OF. DETAILS. 

01012 COMPARE. EMPLOYEE. NUMBERS. GO TO COMPUTE. PAY WHEN DETAIL EMPLOYNO 
°1013 IS EQUAL TO MASTER EMPLOYNO. LOW. DETAIL WHEN DETAIL 

01014 EMPLOYNO IS LESS THAN MASTER EMPLOYNO. 

01015 HIGH. DETAIL. MOVE 'M« TO MASTER ERRORCODE, FILE MASTER IN 

01016 ERROR. FILE. 

°1017 GET MASTER. AT END DO END. OF. MASTERS. 

01018 GO TO COMPARE. EMPLOYEE. NUMBERS. 

02001 LOW. DETAIL. MOVE »D« TO DETAIL ERRORCODE, FILE DETAIL IN 

02002 ERROR. FILE. 

02003 GO TO GET. DETAIL. 

02004 END. OF. MASTERS. IF DETAIL EMPLOYNO = HIGH. VALUE THEN GO TO 

02005 END. OF. RUN OTHERWISE SET MASTER EMPLOYNO = HIGH. VALUE. 

02006 END. OF. DETAILS. IF MASTER EMPLOYNO = HIGH. VALUE THEN GO TO 

02007 END. OF. RUN OTHERWISE SET DETAIL EMPLOYNO = HIGH. VALUE, GO 

02008 TO COMPARE. EMPLOYEE. NUMBERS. 

02009 END. OF. RUN. MOVE CORRESPONDING GRAND. TOTAL TO PAYRECORD, FILE 

02010 PAYRECORD, CLOSE ALL FILES. 

02011 STOP 1234. 

02012 COMPUTE. PAY. IF DETAIL HOURS IS GREATER THAN 40 THEN SET DETAIL 

02013 GROSS = (DETAIL HOURS - 40) * MASTER RATE * 1.5. 

02014 SET DETAIL GROSS = DETAIL GROSS + MASTER RATE * 40, DO 

02015 FICA. ROUTINE. DO WI THOLDING. TAX.ROUTI NE. 

02016 IF MASTER BONDEDUCT IS NOT EQUAL TO ZERO THEN DO 

02017 BOND. ROUTINE. 

02018 DO SEARCH FOR INDEX = 1(1)12. 

02019 NET. SET PAYRECORD NETPAY = DETAIL GROSS - DETAIL FICA - DETAIL 

02020 WHT - DETAIL RETIREMENT - DETAIL INSURANCE - DETAIL 

02021 BONDEDUCT. 
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SERIAL NAME TEXT 

03001 ADD CORRESPONDING DETAIL TOTALS TO MASTER TOTALS. MOVE 

03002 CORRESPONDING DETAIL TO PAYRECORD, CHECK, MOVE PAYRECORD 

03003 NETPAY TO CHECK AMOUNT. 

03004 FILE CHECK. 

03005 IF PAYRECORD DEPARTMENT IS GREATER THAN CURRENT DEPARTMEN1 

03006 THEN MOVE BLANKS TO PAYRECORD EMPLOYNO, PAYRECORD NAME, 

03007 MOVE CORRESPONDING DEPARTMENT .TOTAL TO PAYRECORD, FILE 

03008 PAYRECORD, MOVE ZEROS TO DPT HOURS, DPT GROSS, DPT wHT, 

03009 DPT FICA, DPT BONDEDUCT, DPT INSPREM, DPT RETPREM, DPT 

03010 NETPAY, DPT BONDPURCHASES. 

03011 MOVE CORRESPONDING DETAIL TO PAYRECORD, CURRENT, ADD 

03012 CORRESPONDING DETAIL TO DEPARTMENT. TOTAL , GRAND. TOTAL, 

03013 FILE PAYRECORD. 

03014 GO TO GET. MASTER. 



03015 FICA. ROUTINE. BEGIN SECTION. 

03016 IF MASTER FICA + 0.03 * DETAIL GROSS IS LESS THAN 144.00 

03017 THEN SET DETAIL FICA = 0.03 * DETAIL GROSS OTHERWISE SET 

03018 DETAIL FICA = 144.00 - MASTER FICA. 

03019 ADD DETAIL FICA TO MASTER FICA. 

03020 END FICA. ROUTINE. 



04001 WITHOLDING. TAX. ROUTINE. BEGIN SECTION. 

04002 IF 13 * MASTER EXEMPTIONS IS LESS THAN DETAIL GROSS THEN 

04003 SET DETAIL WHT = 0.18 * (DETAIL GROSS - 13 * MASTER 

04004 EXEMPTIONS) OTHERWISE SET DETAIL WHT = ZEROS. 

04005 ADD DETAIL WHT TO MASTER WHT. 

04006 END WITHOLDING. TAX. ROUTINE, 

04007 BOND. ROUTINE. BEGIN SECTION. 

04008 ADD MASTER BONDEDUCT TO MASTER BONDACCUM. 

04009 BOND.CALCULATION. IF MASTER BONDENOM IS NOT GREATER THAN MASTER 

04010 BONDACCUM THEN SET MASTER BONDACCUM = MASTER BONDACCUM - 

04011 MASTER BONDENOM OTHERWISE GO TO BOND. END. 

04012 MOVE CORRESPONDING MASTER TO BONDORDER, ADD BONDORDER 

04013 BONDENOM TO DPT BONDPURCHASES, MOVE BONDORDER BONDENOM TO 

04014 PAYRECORD BONDENOM, FILE BONDORDER IN EkkOR.FILE. 

04015 GO TO BOND.CALCULATION. 

04016 BOND. END. END BOND. ROUTINE. 

04017 SEARCH. BEGIN SECTION. 

04018 IF MASTER RATE GT TABLE. ITEM RATE (INDEX) THEN GO TO 

04019 SEARCH. END OTHERWISE ADD TABLE. ITEM INSPREM (INDEX) TO 

04020 DETAIL INSURANCE, ADD TABLE. ITEM RETPREM (INDEX) TO DETAIL 

04021 RETIREMENT, GO TO NET. 

04022 SEARCH. END. END SEARCH. 
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SERIAL NAME 
05001 *DATA 



LV TYPE QUAN MJ DESCRIPTION 



05002 MASTER 1RECORD 

05003 ERRORCODE 2 

05004 DATA 2 



05005 EMPLOYEE. NUMBER 3 

05006 DEPARTMENT 4 

05007 EMPLOYEE 4 



05008 


NAME 


3 


05009 


RATE 


3 


05010 


DATE 


3 


05011 


MONTH 


4 


05012 


DAY 


4 


05013 


YEAR 


4 



05014 EXEMPTIONS 3 

05015 TOTALS 3 

05016 GROSS 4 

05017 RETIREMENT 4 

05018 INSURANCE 4 

05019 FICA 3 

05020 WHT 3 

05021 BONDEDUCTION 3 

05022 BONDACCUMULATION 2 

05023 BONDENOMINATION 2 

05024 2 



99 
9999 



A(15) 
99V999 



99 
99 
99 

99 



99999V99 

999V99 

999V99 

999V99 

9999V99 

99V99 

999V99 
999V99 
AAA 



06001 DETAIL 



1RECORD 



06002 ERRORCODE 

06003 HOURS 



06004 DATA 



06005 EMPLOYEE. NUMBER 3 

06006 DEPARTMENT 4 

06007 EMPLOYEE 4 



A 
99V9 



99 

9999 



06008 NAME 



A(15) 



06009 


DATE 


3 


06010 


MONTH 


4 


06011 


DAY 


4 


06012 


YEAR 


4 


06013 


EXEMPTIONS 


3 


06014 


TOTALS 


3 


06015 


GROSS 


4 


06016 


RETIREMENT 


4 


06017 


INSURANCE 


4 


06018 


FICA 


3 


06019 


WHT 


3 


06020 


BONDEDUCTION 


3 



06021 BONDACCUMULATION 2 

06022 BONDENOMINATION 2 

06023 2 



99 
99 
99 

99 



99999V99 

999V99 

999V99 

999V99 

9999V99 

99V99 

999V99 
999V99 

AAAAA 
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SERIAL NAME 
07001 BONDOROER 



LV TYPE QUAN MJ 

1RECORD L 



DESCRIPTION 



CONT 



07002 EMPLOYEE. NUMBER 2 

07003 DATE 2 

07004 BONDENOMINATION 2 

07005 NAME 2 



9J6) 
9(6) 
999V99 
AC15) 



07007 CHECK 



1RECORD 



07008 EMPLOYEE. NUMBER 2 

07009 DEPARTMENT 3 

07010 EMPLOYEE 3 



99 
9999 



U7011 
07012 



NAME 
AMOUNT 



A<15) 
5***9.99 



08001 PAYRECORD 1RECORD 

08002 EMPLOYEE. NUMBER 2 

08003 DEPARTMENT 3 

08004 3 

08005 EMPLOYEE 3 



99 

A 

9999 



08006 




2 


08007 


NAME 


2 


08008 


DATE 


2 


03009 




3 


08010 


MONTH 


3 


08011 




3 


08012 


DAY 


3 


08013 




3 


08014 


YEAR 


3 


08015 


HOURS 


2 


08016 


GROSS 


2 


08017 


WHT 


2 


08018 


FICA 


2 


08019 


BONDEDUCTION 


2 


08020 


INSURANCE 


2 


08021 


RETIREMENT 


2 


08022 


NETPAY 


2 


08023 


BONDENOMINATION 


2 



A 
A(153 



A 

99 

A 

99 

A 

99 

8889.9- 

$88889.99- 

$88889.99- 

$8889.99- 

$8889.99- 

$8889.99- 

$8889.99- 

$88889.99- 

$88899.99- 



09001 DEPARTMENT. TOTAL 1RECORD 



09002 


HOURS 


2 


09003 


GROSS 


2 


09004 


WHT 


2 


09005 


FICA 


2 


09006 


BONDEDUCTION 


2 


09007 


INSURANCE. PREM 


2 


09008 


RETIREMENT. 


2 


09009 


PREM 




09010 


NETPAY 


2 


09011 


BONDPURCHASES 


2 



9999V9 

9(5)V99 

9(5)V99 

9999V99 

9999V99 

9999V99 

9999V99 
9(5)V99 
9C5JV99 



09012 GRAND.TOTAL 



1C0PY 



DEPARTMENT. TOTAL 



10001 TABLE 

10002 

10003 

10004 

10005 

10006 

10007 



•0099908006001499100060' 
•0199912009002499150090 » 
•0299915012003499200120' 
•03999200150044992 50150' 
'04999300180064993002 50' 
•07999300 350999 99300500' 



10009 


TABLE. ITEM 


2 


12 




10010 


RATE 


3 




99V999 


10011 


INSURANCE. PREM 


3 




9V99 


10012 


RETIREMENT. PREM 


3 




9V99 


10013 


CURRENT 


1RECORD 






10014 


DEPARTMENT 


2 




99 


10015 


INDEX 


2 
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Appendix 2: 



Supplementary Information 



Rules for Forming 

Conditional 

Expressions 



Conditional expressions may contain the names of conditions, variables, constants 
and functions, as well as literals, arithmetic operators, relations of equality and rela- 
tive magnitude and the operators not, and and or. Subexpressions may be contained 
in parentheses as required. 

If a conditional expression (such as married or pay is greater than 2 * x + y) 
is designated by the symbol Ci the following rules may be stated concerning the 
formation of conditional expressions involving Ci, not, and and or. 



1. The Conditional Expression 

CI 

NOT CI 
CI AND C2 
CI OR C2 

NOT (CI AND C2) 

NOT (CI OR C2) 



Is True If 

CI is true 

CI is false 

Both CI and C2 are true 

Either CI is true, C2 is true, 
or both are true 

CI is false, C2 is false, 
or both are false 

CI and C2 are both false 



2. If CI and C2 are conditional expressions, then "CI AND C2" and "CI OR C2" 
are conditional expressions, as are similar expressions formed with the use of 
not. Thus, an expression of the form 

CI AND (C2 OR NOT (C3 OR C4) ) 

may be successively reduced by substituting as follows: 

Let C5 equal "C3 OR C4" ► CI AND (C2 OR NOT C5) 

Let C6 equal"C2 OR NOT C5" > C1ANDC6 

Let C7 equal "CI AND C6" > C7 

This rule indicates how conditional expressions may be formed from conditional 
expressions. 

3. The conditional expression "CI OR C2 AND C3" is identical with "CI OR 
(C2 AND C3)" but is not the same as "(CI OR C2) AND C3." In other words, 
conditional expressions are grouped first according to and and subsequently by 
or. However, the programmer's use of parentheses will affect the order of 
grouping. 

4. The rules for formation of symbol pairs are contained in the following table: 
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Rules for Forming 

Arithmetic 

Expressions 











Second Symbol 






C 


OR 


AND 


NOT 


( 


) 


"5 
£ 

4- 

IZ 


c 





1 


1 








1 


OR 


1 








1 


1 





AND 


1 








1 


1 





NOT i 


1 












1 







1 





i 


i 





> 





1 


1 








1 



where the "1" indicates that the pair is permissible, and the "0" indicates a sym- 
bol pair that is not permissible. Thus, the pair "or not" is permissible, while 
"not or" is not permissible. 

Arithmetic expressions may contain the names of variables, constants and func- 
tions, also literals and conditional expressions, joined by arithmetic operators. Sub- 
expressions may be contained in parentheses as required. The rules for forming 
arithmetic expressions are as follows: 



1. The basic operators are: 



Binary Operator 


Written as 


Addition 


+ 




Subtraction 


— 




Multiplication 


* 




Division 


/ 




Exponentiation 


** 




Unary Operator 


Written as 


Negation 


— 




Absolute Value 


ABS 




Truth Value 


TR 





2. The ways in which symbol pairs may be formed are summarized in the follow- 
ing table : 







i 

i 




Second Symbol 








Variable 


+ -*/ 


** 


ABS, 
TR 


Negation 


( 


) 


"o 

ja 

E 

<ft 

+■ 

«n 
u 

IE 


Variable 





1 











1 


_l_ — * / ** 


1 





1 





1 





ABS, TR 


1 











1 





Negation 


1 











1 





( 


1 





1 


1 


1 





) 





1 











1 

- 



where "1" indicates a permissible symbol pair, and "0" indicates a pair which is 
not permitted. Thus, "* (" is permissible, while "( *" is not. 



106 



When the hierarchy of operations in an expression is not completely specified 
by parentheses, the order of operations (working from inside to outside) is as- 
sumed to be exponentiation, then multiplication and division, and finally addi- 
tion and subtraction. Thus the expression A + B/C + D**E*F - G will be 
taken to mean A + (B/C) + (D E • F) - G. 

When the sequence of consecutive operations of the same hierarchal level (i.e., 
consecutive multiplications and divisions or consecutive additions and subtrac- 
tions) is not completely specified by parentheses, the order of operations is as- 
sumed to be from left to right. Thus expressions ordinarily considered ambiguous, 
e.g., A/B • C and A/B/C, are permitted in Commercial Translator statements. 
For instance, the expression A*B/C*D is taken to mean ((A*B)/C)*D. 

The expression A B °, which is sometimes considered meaningful, cannot be written 
as A**B**C; it should be written as (A**B)**C or A**(B**C), whichever is 
intended. 
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List of Commercial Translator Commands 



The general forms of all of the Commercial Translator commands are presented 
below in alphabetic order for reference purposes. In order to make the list as concise 
as possible, optional words and phrases are shown enclosed in brackets, - [ ]; the 
brace, ( , is used to indicate a choice of one of two or more variant forms. 



ADD [CORRESPONDING"] data -™me.l TO data.name.2, data.name.3, 
. . . data.name.n 

BEGIN SECTION [uSING parameter .1 , parameter.2, 

parameter.^ [GIVING function.l, function.2, . . . function.nl 



"ALL {old.name.l) new. name. 1, [old. name. 2) new. name. 2, 
{old.name.n) new.name.n 



f f He. name. 1, file .name. 2, . . . file. name. n 
CLOSE <{ 

I ALL FILES 



'any message' 
DISPLAY <J data.name 

any combination of the above 



"DO procedure. name [EXACTLY n TMEs] [\JSING data. name. 1, data.name.2, .. 
data.name. n~\ [GIVING r e suit. name. 1, result. name. 2, ... result. name. n\ 

DO procedure, name FOR index.name.l = p.l{q.l)r.l\ ', index, name. 2 = 

p.2(q.2)r.2, index.name.3 = p.3(q.3)r.3^ [USING data.name. 1, data.name.2, 
. . . data.name.^ [GIVING r e suit. name. 1, result. name. 2, . . . result. name. n\ 

END procedure . nam e 
ENTER coding. language 



FTT.E w^n«J «/■«« I TNT -r;i „ ........ I 
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r RECORD FROM filename^ 
GET< >AT END any imperative clause 

I record.name J 



GO TO procedure .name 

GO TO procedure. name. 1 WHEN conditional expression 1, 
procedure. name. 2 WHEN conditional expression 2, . . . 
procedure. name. n WHEN conditional expression n 

GO TO (procedure. 1, procedure.2, . . . procedure.n) ON index.name 

INCLUDE I HERE J library .procedure AS procedure. name\ WITH new.name.l FOR 
old.name.l, new.name.2 FOR old.name.2, . . . new.name.n FOR old.name.n 

LOAD procedure. name 

MOVE [CORRESPONDINGJ data.name.l TO data.name.2, data.name.3, 

. . . data.name.n 

NOTE any sentence. 



T f He. name. 1, file. name. 2, . . . file.name.n 
OPEN<^ 

I ALL FILES 



OVERLAP procedure .name .1 , procedure. name. 2, . . . procedure. name. n 

SET variable. 1, variable. 2, ... variable. n = arithmetic expression 
[TRUNCATED^ |~, ON OVERFLOW any imperative clause] 

SET condition. name 



STOP n 



109 



List of Commercial Translator Words 



All those words which are a fixed part of the Commercial Translator vocabulary are 
listed below. The words are presented here to assist the programmer in avoiding the 
use of any of them when choosing data-names and procedure-names. 



ABS 


GET 




ADD 


GIVING 


OTHERWISE 


ALL 


GO 


OVERFLOW 


AND 


GREATER 


OVERLAP 


AS 


GT 




AT 


HERE 


fPARAM 


BEGIN 


HIGH. VALUE 


tQUANTITY 


BLANK 


HIGH. VALUES 




BLANKS 




RECORD 




IF 


fREDEF 


CALL 


IN 




CLOSE 


INCLUDE 


SECTION 


COMMERCIAL 


IS 


SET 


fCOND 




STOP 


fCOPY 


fLABEL 




CORRESPONDING 


LESS 


THAN 




tLIBRARY 


THEN 


DISPLAY 


LOAD 


TIMES 


DO 


LOW. VALUE 






LOW.VALUES 


TR 


END 


LT 


TRANSLATOR 


ENTER 




TRUNCATED 


EQUAL 


MOVE 




EXACTLY 


NOT 


USING 


FILE 


NOTE 


WHEN 


FILES 




WITH 


FOR 


ON 




FROM 


OPEN 


ZERO 


jFUNCT 


OR 


ZEROS 



fThese words have a restricted usage only in data description; they may be used 
freely in procedure description. 
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Appendix 3: 



Glossary 



Following is a list of important terms which are used frequently in this manual, in- 
cluding a number which have certain specialized meanings when used with respect to 
the Commercial Translator system. The definitions given in this glossary are not 
exhaustive, and the reader is referred to the text of the manual for amplification 
when required. 



ABSOLUTE VALUE 



ADDRESS 



The value, or magnitude, of a number, regardless of sign. When used arithmetically, the 
absolute value is treated as having a plus sign. 

In data processing, a specific location within storage, or a specific item or feature of data 
processing equipment. In the Commercial Translator language, addresses are represented 
by names. Actual address, absolute address, or machine address — an address defined in 
terms of the operating specifications of a data processing system; such addresses are not 
used by the programmer in writing Commercial Translator programs. 



ALPHABETIC 



With respect to data, consisting of one or more non-numeric characters, including the 
blank. As used in the Commercial Translator system, the term is not limited to the letters 
of the alphabet. 



ALPHAMERIC 



In the Commercial Translator system, consisting of any of the characters of a machine's 
character set, except that an alphameric literal may not contain a quotation mark. (See 
the rules governing literals in Chapter 2.) 



ARITHMETIC 
EXPRESSION 



An expression containing any combination of data-names, literals, constants, and truth 
functions, joined together by one or more arithmetic operators in such a way that the 
expression as a whole can be reduced to a single numeric value. (See the discussion of 
arithmetic expressions in Chapter 2 and the commands set and add in Chapter 3.) 



CHARACTER 



One of a set of elementary symbols which may be arranged in ordered groups to express 
information. These symbols may include the decimal digits through 9, the letters A 
through Z, punctuation symbols, special input and output symbols, and any other symbols 
which may be accepted by a data processing system. 



CLAUSE 



In the Commercial Translator language, a group of words (including symbols where ap- 
propriate) which either expresses a complete command or defines a condition to be tested. 
(See also imperative clause and conditional clause.) 



CLOSED SUBROUTINE 



COMMAND 



In the Commercial Translator system, a section of procedure which is executed by means 
of a do command. Also called a linked subroutine. (See also open subroutine.) 

In the Commercial Translator language, a verb and its associated operand(s). 



COMPOUND NAME 



CONDITION 



CONDITIONAL CLAUSE 



In the Commercial Translator language, a name consisting of two or more simple names 
combined for the purpose of making the right-most one unique, in accordance with the 
rules given in Chapter 2 of this manual. 

In the Commercial Translator language, the presence of a specified value in a variable 
field. (See conditional expression.) 

A clause containing a conditional expression introduced by the word if and terminated 
by the word then. 



Ill 



CONDITIONAL 
EXPRESSION 



CONDITION-NAME 



CONSTANT 



DATA DESCRIPTION 



DATA-NAME 



DIVISION HEADER 



ENVIRONMENT 
DESCRIPTION 



FIELD 



FIELD PICTORIAL 



In the Commercial Translator language, an expression which has the particular character- 
istic that, taken as a whole, it may be either true or false, in accordance with the rules 
given in Chapter 2 of this manual. 

A name assigned by the programmer to a value, representing one of several conditions, 
which may be present in a data field, in accordance with the rules given in Chapter 2 of 
this manual. 

A value which is to be used in a program without alteration, in accordance with the rules 
given in Chapter 2 of this manual. While a literal may be thought of as a special form 
of constant, most constants have names which are specified by data description entries, 
as explained in Chapter 4. 

That portion of a Commercial Translator program which consists of entries defining the 
nature and characteristics of the data to be used in the program. The data description is 
one of the three main divisions of a Commercial Translator program, the others being the 
procedure description and the environment description. (See Chapter 4.) 

A name assigned by the programmer to an item of data for use in a Commercial Trans- 
lator program, in accordance with the rules given in Chapter 2 of this manual. 

One of three special words used to identify the beginning of a main portion of a Com- 
mercial Translator source program. The three words are *data, *environment, and 
* procedure, identifying, respectively, portions of the data description, environment 
description, and procedure description divisions. 

That portion of a Commercial Translator program in which the programmer specifies the 
equipment and equipment features to be used in a program, such as the nature of the 
input and output equipment, the size and nature of the storage area available, and so on. 
This subject is discussed in the manuals covering the processors for the various data 
processing systems. 

In the Commercial Translator system, an item of data which can be operated upon by the 
arithmetic and/ or data transmission verbs. It is usually thought of as a small unit or 
element of data, as opposed to a record, which is usually composed of a number of fields. 

The representation of the nature and length of an item of data by means of the Commer- 
cial Translator format characters, in accordance with the rules given in Chapter 4 of this 
manual. 



FIGURATIVE CONSTANT 



One of several constants which have been i! pre-named" and "pre-defined" in a Commer- 
cial Translator processor so that they can be written in the procedure statements without 
data description entries. The figurative constants are blank(s), zero(s), high.value(s), 
and low.value(s). 



FILE (noun) 



In the Commercial Translator system, a body of data, stored in some external medium, 
which can be made accessible to the system by the verb open. 



FIXED WORD 



One of a selected list of words having special meanings in the Commercial Translator 
system and not available to the programmer except in accordance with the rules specified 
in this manual. A list of fixed words appears in Appendix 2 of this manual. 



FLOATING POINT 



A form of representing a number x by a pair of numbers y and z in the form x = y X b z , 
where b is the number base used. In the decimal system, b = 10; in the binary system, 
b = 2. The decimal system is used in the Commercial Translator source language. To 
illustrate: the number 127.6 would normally be represented as .1276 X 10 3 (or, in Com- 
mercial Translator notation, .1276F3). The quantity y is called the fraction or mantissa, 
and in the best notation lies between and 1. The quantity z is called the exponent or 
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FORMAT CHARACTER 



FUNCTION 



FUNCTION-NAME 
HEADER 
IMBEDDED PERIOD 

IMPERATIVE CLAUSE 
INSTRUCTION 



power. This form is used mainly in scientific calculation where the size of computed quan- 
tities is difficult to predict and allow for. 

One of the characters specified in the table of format characters in Chapter 4 of this 
manual for indicating the characteristics of data in the data description portion of a 
Commercial Translator program. 

In the Commercial Translator system, a result obtained as a consequence of a procedure; 
specifically, a result named in the giving clause of a begin section command. (See the 
discussion of functions in Chapter 2 of this manual, and the begin section command in 
Chapter 3.) 

A name assigned to a function by the programmer. (See function.) 

(See division header.) 

A period contained within a Commercial Translator name in such a way that it is not 
adjacent to a blank. 

A clause expressing a complete command; it consists of a verb and its operand(s). 

A code, symbol, or group of symbols, which causes a data processing system to perform 
an operation of some kind. An instruction usually consists of a code specifying a kind of 
operation, and an address which indicates the data and/ or item of equipment on which 
the operation is to be performed. 



INTEGER 
JUSTIFICATION 

LEVEL 

LITERAL 



A whole number. E.g., 54 is an integer, while 54.6 is not. 

1. In printing or listing, the alignment of a margin. 2. In the internal storage of data 
within a processing system, the alignment of data with respect to the left or right bounda- 
ries of machine words, as explained in Chapter 4 of this manual. 

In the Commercial Translator system, the status of one item of data relative to another, 
showing whether one is to be treated as a part of the other or whether they are unrelated, 
as specified in the rules governing level numbers in Chapter 4 of this manual. 

A value expressed literally in a procedure statement, as opposed to a value represented 
by a name. Thus, 2 is a literal, whereas the name two could be one of a number of pos- 
sible names used to represent the value 2. (See the rules governing literals in Chapter 2 
of this manual.) 



LOOP 

MACHINE LANGUAGE 

MACHINE WORD 
MACHINE-INDEPENDENT 



A coding technique whereby a group of instructions is repeated, usually with modification 
of at least one of the instructions in the group and/ or with modification of the data being 
operated upon. 

The system of codes by which instructions and data are represented internally within a 
particular data processing system. 

(See word.) 

An adjective used to indicate that an instruction or a program is conceived, organized, or 
oriented without specific reference to the technical characteristics of any one data process- 
ing system. Use of this adjective usually implies that the instruction or program is 
oriented or organized in terms of the logical nature of a problem, rather than in terms of 
the technical means of solving it. 
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MEMORY 
MODE 

NUMERIC 

OBJECT PROGRAM 

OBJECT TIME 
OPEN SUBROUTINE 

OPERAND 
OPERATOR 



PARAMETER 



PARAMETER-NAME 



PROCEDURE 



PROCEDURE DESCRIPTION 



PROCEDURE-NAME 

PROCESS TIME 
PROCESSOR 
PROCESSOR VERBS 

PROGRAM 



Main storage. (See storage.) 

A system of data representation used within the storage section of a data processing 
system. 

1. With respect to data, having a numeric value. 2. With respect to literals, consisting 
wholly of numerals and their included decimal points, plus and minus signs, and floating 
point symbols, if any. 

A program in machine language resulting from the translation of a source program by a 
processor. 

The time at which an object program is executed. 

In the Commercial Translator system, a section of procedure which is executed by a 
means other than the do command. Also called an "in-line" subroutine. (See also closed 

SUBROUTINE.) 

In the Commercial Translator language, the "object" of a verb — i.e., the data or equip- 
ment governed, or operated on, by a verb. 

In the Commercial Translator language, a word or symbol, other than a verb, which 
directs the data processing system to take some action. E.g., the arithmetic operator + 
instructs the system to perform an addition, and the conditional operator if directs it to 
test a conditional expression. 

In the Commercial Translator system, a value used in a procedure to obtain a result; 
specifically, an item of data named in the using clause of a begin section command. 
(See the discussion of functions in Chapter 2 of this manual, and the begin section 
command in Chapter 3.) 

A name assigned to a parameter by the programmer. (See parameter.) 

In the Commercial Translator system, a sequence of one or more instructions used to 
perform some operation. A routine or subroutine. 

That portion of a Commercial Translator program which consists of instructions direct- 
ing the data processing system to take specified actions. The procedure description is one 
of the three main divisions of a Commercial Translator program, the others being the 
data description and the environment description. 

A name assigned by the programmer to a procedure for use in a Commercial Translator 
program, in accordance with the rules given in Chapter 2 of this manual. 

The time at which a source program is translated into an object program. 

A specialized program used to translate a source program into an object program. 

Verbs which give instructions to the processor to be acted upon at the time the source 
program is being translated into the object program. Such verbs do not act at object time. 

A complete sequence of instructions directing a data processing system to perform an 
operation. The term implies an extended sequence incorporating all of the detailed steps 
and subroutines required to complete a job. (See also object program and source 
program.) 
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PROGRAM VERBS 



QUALIFICATION 



Verbs which cause the processor to generate machine instructions which will be part of 
the object program. 

With reference to Commercial Translator names, the technique of modifying a name by 
the addition of another name in order to make it unique, in accordance with the rules 
given in Chapter 2 of this manual. A qualified name is generally known as a compound 
name. 



RECORD 



RELATIONAL EXPRESSION 



ROUND 



In the Commercial Translator system, a sequence of data which can be made accessible 
to the system by the verb get. A record usually consists of a number of fields. 

In the Commercial Translator language, an expression that describes a relationship be- 
tween two terms. E.g., a is greater than b, or x is equal to 10. 

To shorten a number by applying some rule to adjust the least significant remaining digit. 
In the Commercial Translator system, this digit is increased by 1 when the part removed 
is greater than or equal to one-half. Thus, in the decimal system the number 1 26.5027 
would be rounded to 127, because the last number removed is 5 or greater. Rounding 
need not occur just at decimal points. For a 6-position field the number would be rounded 
to 126.503; for a 2-position field it would be rounded to 13, which would be understood 
to be 130. 



ROUTINE 



In the Commercial Translator system, a sequence of one or more instructions used to 
perform some operation. A procedure or subroutine. 



SECTION 



In the Commercial Translator language, one or more consecutive sentences defined in 
accordance with the instructions governing the begin section and end commands, as 
explained in Chapter 3 of this manual. 



SENTENCE 



In the Commercial Translator language, a complete statement specifying one or more 
operations, in accordance with the rules given in Chapter 2 of this manual. It is always 
terminated by a period. 



SOURCE LANGUAGE 



As used in this manual, the Commercial Translator language. 



SOURCE PROGRAM 

STATEMENT 

STORAGE 



As used in this manual, a program written in the Commercial Translator language. 

As used in this manual, a clause or a sentence. 

A medium in which data may be retained. Storage may be internal or external. Main 
storage — the principal internal area in which data is retained for active use within a data 
processing system. Auxiliary storage — a supplementary storage medium, less active in 
use than main storage, in which data may be retained; data in auxiliary storage can be 
addressed directly by the system, but access is generally slower than to main storage. 



STORED PROGRAM 



A data processing program which is stored internally, within a data processing system. 
The program itself occupies storage in the same manner as the data used in the program 
and may be treated as if it were data. 



SUBROUTINE 



In the Commercial Translator system, a sequence of one or more instructions used to 
perform some operation. A procedure or routine. 



SUBSCRIPT 



An integer used to identify a particular item in a list or table, in accordance with the 
rules specified in Chapter 2 of this manual. It may be written in a Commercial Translator 
program as a numeric literal, a data-name, or a limited form of arithmetic expression. 
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TRUNCATED 



Shortened by dropping the less significant digits of a number, as opposed to rounded. (See 
round.) E.g., the number 2063,78 becomes 2063.7 when truncated, 2063.8 when 
rounded. 



TRUTH FUNCTION 



UNARY OPERATOR 



An expression consisting of the truth operator tr, followed by a conditional expression, 
in accordance with the rules given in Chapter 2 of this manual. A truth function acquires 
a value of 1 if the conditional expression is true, a value of if the expression is false. 

An operator which refers to a single data-name or parenthetical expression; e.g., abs is a 
unary operator. 



VARIABLE 



In the Commercial Translator system, a field in storage which may contain different val- 
ues at different times during the running of the object program. 



VERB 



In the Commercial Translator language, one of a selected list of words that cause a data 
processing system to take an action. (See Chapter 3 of this manual.) 



WORD 



In the Commercial Translator language, a basic unit of the language, serving the same 
general purposes as words in other languages. Machine word — a subdivision of storage 
having a fixed size. 
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